From tanner at real-time.com Sun Jul 1 05:24:27 2001 From: tanner at real-time.com (Bob Tanner) Date: Mon Jan 17 14:29:22 2005 Subject: [TCLUG] Re: [TCLUG-DEVEL] Any Cybercash people? In-Reply-To: <3B3DCEDD.2060406@ringworld.org>; from dieman@ringworld.org on Sat, Jun 30, 2001 at 09:06:37AM -0400 References: <20010630015337.B3469@real-time.com> <3B3DCEDD.2060406@ringworld.org> Message-ID: <20010701052427.A15147@real-time.com> Quoting Scott M. Dier (dieman@ringworld.org): > > Anyone worked with Cybercash enough to understand the -implementation- > > details? > > > I think theres a module in CPAN for it. But I might be wrong. I went to http://search.cpan.org/ and searched for cybercash, got nothing. Is that the best way to search CPAN? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Thu Jul 5 03:20:42 2001 From: tanner at real-time.com (Bob Tanner) Date: Mon Jan 17 14:29:22 2005 Subject: [TCLUG-DEVEL] Java reflection and getClasses()? Message-ID: <20010705032042.F29335@real-time.com> Having problems with Java reflection. public class A { public MyClassB myB; public MyClassC myC; public void count(Object obj) { Class myClass = obj.getClass(); Class[] publicClasses = myClass.getClasses(); System.out.println("Num public classes:"+publicClasses.length); } That code snippet returns 0, shouldn't it return 2? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From jpschewe at mtu.net Thu Jul 5 04:24:30 2001 From: jpschewe at mtu.net (Jon Schewe) Date: Mon Jan 17 14:29:22 2005 Subject: [TCLUG-DEVEL] Java reflection and getClasses()? In-Reply-To: <20010705032042.F29335@real-time.com> References: <20010705032042.F29335@real-time.com> Message-ID: Why? Really depends on what the datatype of obj really is. If it's an instanceof A, then it should return 0 because A does not implement any interfaces and there are no public member classes. Bob Tanner writes: > Having problems with Java reflection. > > public class A { > public MyClassB myB; > public MyClassC myC; > > public void count(Object obj) { > Class myClass = obj.getClass(); > Class[] publicClasses = myClass.getClasses(); > System.out.println("Num public classes:"+publicClasses.length); > } > > That code snippet returns 0, shouldn't it return 2? > > > > -- > Bob Tanner | Phone : (952)943-8700 > http://www.mn-linux.org | Fax : (952)943-8500 > Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 > > _______________________________________________ > tclug-devel mailing list > tclug-devel@mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel -- Jon Schewe | http://mtu.net/~jpschewe | jpschewe@mtu.net For I am convinced that neither death nor life, neither angels nor demons, neither the present nor the future, nor any powers, neither height nor depth, nor anything else in all creation, will be able to separate us from the love of God that is in Christ Jesus our Lord. - Romans 8:38-39 From kethry at winternet.com Thu Jul 5 09:16:45 2001 From: kethry at winternet.com (Liz Burke-Scovill) Date: Mon Jan 17 14:29:22 2005 Subject: [TCLUG-DEVEL] Java reflection and getClasses()? In-Reply-To: <20010705032042.F29335@real-time.com> Message-ID: On Thu, 5 Jul 2001, Bob Tanner wrote: > Having problems with Java reflection. > > public class A { > public MyClassB myB; > public MyClassC myC; > > public void count(Object obj) { > Class myClass = obj.getClass(); > Class[] publicClasses = myClass.getClasses(); > System.out.println("Num public classes:"+publicClasses.length); > } > > That code snippet returns 0, shouldn't it return 2? Why? you don't have any reference to a class that has the other publicClasses. Ie., and perhaps my eyes are just too tired this morning, Where are you defining obj as an object of A? (I'm assuming this since you said it should return two, and I'm assming that's refering to MyClassB and MyClassC. Liz -- Imagination is intelligence having fun... e-mail: kethry@winternet.com URL: http://WWW.winternet.com/~kethry/index.html From mike at fruitioninc.com Sat Jul 7 20:37:57 2001 From: mike at fruitioninc.com (Mike Bresnahan) Date: Mon Jan 17 14:29:22 2005 Subject: [TCLUG-DEVEL] Source Level Debugging of JDK Classes? Message-ID: <05e001c1074e$9d685af0$0300000a@anelginanalas> Has anyone done any source level debugging of the JDK classes using jdb or JSwat? It doesn't work out of the box presumably because the JDK is not compiled with -g. I've seen it work with Visual Age Java, but I don't have access to that IDE currently. My next step is to compile the JDK source code myself passing -g to the compiler. I thought perhaps someone else might have done this before me, but google is not turning anything up for me. Mike From dieman+tclug at ringworld.org Sat Jul 7 20:06:14 2001 From: dieman+tclug at ringworld.org (Scott Dier) Date: Mon Jan 17 14:29:22 2005 Subject: [TCLUG-DEVEL] Source Level Debugging of JDK Classes? In-Reply-To: <05e001c1074e$9d685af0$0300000a@anelginanalas> Message-ID: <20010707200614.E21209@ringworld.org> * Mike Bresnahan [010707 18:38]: > Has anyone done any source level debugging of the JDK classes using jdb or > JSwat? It doesn't work out of the box presumably because the JDK is not I've messed with Forte and its worked before. -- Scott Dier http://www.ringworld.org/ #linuxos@irc.openprojects.net From tanner at real-time.com Tue Jul 10 02:04:40 2001 From: tanner at real-time.com (Bob Tanner) Date: Mon Jan 17 14:29:22 2005 Subject: [TCLUG-DEVEL] JCE dog slow? Message-ID: <20010710020440.C10115@real-time.com> Is my code just crap, or is the JCE slow? Doing -single- DES on a 140 byte array is taking an avg of 4 sec! Triple DES is off the scale. It's almost unusable. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From dieman+tclug at ringworld.org Tue Jul 10 10:05:07 2001 From: dieman+tclug at ringworld.org (Scott Dier) Date: Mon Jan 17 14:29:22 2005 Subject: [TCLUG-DEVEL] JCE dog slow? In-Reply-To: <20010710020440.C10115@real-time.com> Message-ID: <20010710100507.J30232@ringworld.org> * Bob Tanner [010710 02:08]: > Doing -single- DES on a 140 byte array is taking an avg of 4 sec! I'm going to tell you right now. Use single DES for anything and you rot in heck. I don't know why DES would be so HORRIBLY slow though. Do you have any example code of what your doing in that part of your code? It might be something your doing thats triggering something nasty to be done. -- Scott Dier http://www.ringworld.org/ #linuxos@irc.openprojects.net From mike at fruitioninc.com Tue Jul 10 12:57:55 2001 From: mike at fruitioninc.com (Mike Bresnahan) Date: Mon Jan 17 14:29:22 2005 Subject: [TCLUG-DEVEL] JCE dog slow? References: <20010710020440.C10115@real-time.com> Message-ID: <081201c10969$d8f2a040$0300000a@anelginanalas> Download a eval copy of Rational Quantify and profile your code. Hey, do you know of any opensource profilers - cpu and/or memory? That would be a cool project. Mike ----- Original Message ----- From: "Bob Tanner" To: Sent: Tuesday, July 10, 2001 12:04 AM Subject: [TCLUG-DEVEL] JCE dog slow? > Is my code just crap, or is the JCE slow? > > Doing -single- DES on a 140 byte array is taking an avg of 4 sec! > > Triple DES is off the scale. > > It's almost unusable. > > -- > Bob Tanner | Phone : (952)943-8700 > http://www.mn-linux.org | Fax : (952)943-8500 > Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 > > _______________________________________________ > tclug-devel mailing list > tclug-devel@mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel From jpschewe at mtu.net Tue Jul 10 23:17:46 2001 From: jpschewe at mtu.net (Jon Schewe) Date: Mon Jan 17 14:29:22 2005 Subject: [TCLUG-DEVEL] JCE dog slow? In-Reply-To: <081201c10969$d8f2a040$0300000a@anelginanalas> References: <20010710020440.C10115@real-time.com> <081201c10969$d8f2a040$0300000a@anelginanalas> Message-ID: There's one built into java, use java -hprof. It'll do CPU, but not memory. Check out this article: http://developer.java.sun.com/developer/technicalArticles//Programming/perfanal/index.html "Mike Bresnahan" writes: > Download a eval copy of Rational Quantify and profile your code. > > Hey, do you know of any opensource profilers - cpu and/or memory? That > would be a cool project. > > Mike > ----- Original Message ----- > From: "Bob Tanner" > To: > Sent: Tuesday, July 10, 2001 12:04 AM > Subject: [TCLUG-DEVEL] JCE dog slow? > > > > Is my code just crap, or is the JCE slow? > > > > Doing -single- DES on a 140 byte array is taking an avg of 4 sec! > > > > Triple DES is off the scale. > > > > It's almost unusable. > > > > -- > > Bob Tanner | Phone : (952)943-8700 > > http://www.mn-linux.org | Fax : (952)943-8500 > > Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 > > > > _______________________________________________ > > tclug-devel mailing list > > tclug-devel@mn-linux.org > > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel > > _______________________________________________ > tclug-devel mailing list > tclug-devel@mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel -- Jon Schewe | http://mtu.net/~jpschewe | jpschewe@mtu.net For I am convinced that neither death nor life, neither angels nor demons, neither the present nor the future, nor any powers, neither height nor depth, nor anything else in all creation, will be able to separate us from the love of God that is in Christ Jesus our Lord. - Romans 8:38-39 From tanner at real-time.com Wed Jul 11 00:21:57 2001 From: tanner at real-time.com (Bob Tanner) Date: Mon Jan 17 14:29:22 2005 Subject: [TCLUG-DEVEL] JCE dog slow? In-Reply-To: <20010710100507.J30232@ringworld.org>; from dieman+tclug@ringworld.org on Tue, Jul 10, 2001 at 10:05:07AM -0500 References: <20010710020440.C10115@real-time.com> <20010710100507.J30232@ringworld.org> Message-ID: <20010711002157.D29489@real-time.com> Quoting Scott Dier (dieman+tclug@ringworld.org): > * Bob Tanner [010710 02:08]: > > Doing -single- DES on a 140 byte array is taking an avg of 4 sec! > > I'm going to tell you right now. Use single DES for anything and you > rot in heck. > > I don't know why DES would be so HORRIBLY slow though. Do you have any > example code of what your doing in that part of your code? It might be > something your doing thats triggering something nasty to be done. > public byte[] tripleDES(String clearText) throws NoSuchAlgorithmException, InvalidKeyException, InvalidKeySpecException, IllegalBlockSizeException, InvalidKeyException, NoSuchPaddingException, BadPaddingException { SecretKeyFactory sf = SecretKeyFactory.getInstance("DESede"); SecretKey desKey = sf.generateSecret(new DESedeKeySpec(getSessionKey().getBytes())); Cipher desCipher = Cipher.getInstance("DESede/CBC/PKCS5Padding"); // Initialize the cipher for encryption desCipher.init(Cipher.ENCRYPT_MODE, desKey); // Our cleartext byte[] clearTextBytes = clearText.getBytes(); // Encrypt the cleartext byte[] cipherText = desCipher.doFinal(clearTextBytes); return cipherText; } -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Fri Jul 13 03:46:24 2001 From: tanner at real-time.com (Bob Tanner) Date: Mon Jan 17 14:29:22 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? Message-ID: <20010713034624.B25560@real-time.com> Well, smack me and call me silly. I did not know you could extend interfaces multiple times, kind of like multiple inheritance in C++. Solve a problem for me. But it makes a design question for me. For those who don't know, I am almost done with a 100% Java based CyberCash API, which I'll be releasing to the community in a couple of weeks. So, you have the scope of what I am trying to do here. And here is my design problem. I have 2 interfaces (comments stipped for brevity): public interface CyberCashResponseIF { public Properties getResponse(); public void setResponse(Properties response); } public interface CreditPaymentInformationIF { public String getOrderNumber(); public String getCardType(); public String getCardZip(); public String getCardState(); public String getCardCountry(); public String getCardCity(); public String getCardNumber(); public String getCardName(); public String getCardExp(); public String getCardAddress(); public String getCardAmount(); } These of course represent a response and request to a CyberCash Merchant server. I used the names Cybercash does in their MCK documentation, CreditPaymentInfomation = request in Cybercash lingo. The Cybercash "engine" looks likes like this: public class CyberCash extends Thread { public CyberCash([MY DESIGN QUESION HERE] transaction) { } public void run() {} } Because I extended Thread, I more or less have to pass everything in via the constructor, so every cybercash transactions has a request and a response so what I did what was this: public interface CyberCashTransActionIF extends CreditPaymentInformationIF, CyberCashResponseIF { } Changed Cybercash constructor to this: public CyberCash(CyberCashTransActionIF transaction) { } My question is: Is this a hack? An interface that just extends 2 other interfaces just to combine them into a nice "package" seem wrong to me OO desing side, but my old C-hack side says it works, so do it. Futher design details show that there are some object that just do CreditPaymentInformation and other classes that just do CyberCashResponse, but a majorit of them do both. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From nobody170 at yahoo.com Fri Jul 13 07:00:19 2001 From: nobody170 at yahoo.com (Bill Gladen) Date: Mon Jan 17 14:29:22 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? In-Reply-To: <20010713034624.B25560@real-time.com> Message-ID: <20010713120019.76491.qmail@web10008.mail.yahoo.com> First: >smack< You're silly. Now: It's not a hack. It's a valid way to provide assurance that an object will have all methods required available. Consider: public interface MyFrameworkReadyObjectInterface extends Clonable, Comparable, Serializable ... If there was only one place that needed both interfaces available, then its over-designed, but if it happens all over the place, its a good decision in favor of brevity and clarity. Bill --- Bob Tanner wrote: > Well, smack me and call me silly. > > My question is: Is this a hack? > > An interface that just extends 2 other interfaces just to combine > them into a > nice "package" seem wrong to me OO desing side, but my old C-hack > side says it > works, so do it. > > Futher design details show that there are some object that just do > CreditPaymentInformation and other classes that just do > CyberCashResponse, but a > majorit of them do both. > > > > > -- > Bob Tanner | Phone : (952)943-8700 > http://www.mn-linux.org | Fax : (952)943-8500 > Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 > > _______________________________________________ > tclug-devel mailing list > tclug-devel@mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From mike at fruitioninc.com Fri Jul 13 11:31:18 2001 From: mike at fruitioninc.com (Mike Bresnahan) Date: Mon Jan 17 14:29:23 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? References: <20010713034624.B25560@real-time.com> Message-ID: <007201c10bb9$3e88e9e0$0300000a@anelginanalas> Why not just pass two arguments to the constructor - request and response? That would model how the Servlet API is designed. By the way, my personal taste is to never design an interface or class that has nothing but get()/set() functions. I don't think such a class has enough interesting behavior to be a class of its own. You can easily factor out the reusable behavior of such a class and all bizillion other similar classes into a interface like this: interface Tuple { public Object getValue( String Key); public void putValue( String Key, Object value); } Here's a couple quick examples that illustrate the advantages of this design: - you only need to write one toString() function, not a bizillion - you only need to write one function to insert, update, or delete this tuple from a RDBMS, not a bizillion Thus the design eliminates a lot of redundant code and therefore reduces bugs, complexity, compile time, etc. However it comes at the cost of dynamic typing vs static typing. If I didn't want to pay the costs of dynamic typing and really really wanted it to be statically typed, then I would just create a "struct" like class to be a convenient way of grouping the data elements together. public class CreditPaymentInformationIF { public String orderNumber; //... } You may stop and say, "But its not encapsulated!". But I will counter with, "Yes it is, but the encapsulation barrier is the function that returns the instance of the class." That function is the black box where all the interesting behavior happens. The above class is simply the resulting data. One other thing... it seems possibly bad design to be passing the request and response to a Thread constructor for two reasons. - Creating threads and handling requests are conceptually two different things - one is a performance optimization and the other is a business process. - Creating a thread for every request could be a performance problem You might be better off seperating the two concepts and also using a thread pool and Producer-Consumer pattern to handle incoming requests. If you do it right, the request handler could be generic enough to be reuable by your next server application. You asked for my opinion and you got it. :) Mike ----- Original Message ----- From: "Bob Tanner" To: Sent: Friday, July 13, 2001 1:46 AM Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? > Well, smack me and call me silly. > > I did not know you could extend interfaces multiple times, kind of like multiple > inheritance in C++. Solve a problem for me. But it makes a design question for > me. > > For those who don't know, I am almost done with a 100% Java based CyberCash API, > which I'll be releasing to the community in a couple of weeks. > > So, you have the scope of what I am trying to do here. And here is my design > problem. > > I have 2 interfaces (comments stipped for brevity): > > public interface CyberCashResponseIF { > public Properties getResponse(); > public void setResponse(Properties response); > } > > public interface CreditPaymentInformationIF { > public String getOrderNumber(); > public String getCardType(); > public String getCardZip(); > public String getCardState(); > public String getCardCountry(); > public String getCardCity(); > public String getCardNumber(); > public String getCardName(); > public String getCardExp(); > public String getCardAddress(); > public String getCardAmount(); > } > > These of course represent a response and request to a CyberCash Merchant server. > I used the names Cybercash does in their MCK documentation, > CreditPaymentInfomation = request in Cybercash lingo. > > The Cybercash "engine" looks likes like this: > > public class CyberCash extends Thread { > public CyberCash([MY DESIGN QUESION HERE] transaction) { } > public void run() {} > } > > Because I extended Thread, I more or less have to pass everything in via the > constructor, so every cybercash transactions has a request and a response so > what I did what was this: > > public interface CyberCashTransActionIF > extends CreditPaymentInformationIF, CyberCashResponseIF { > } > > Changed Cybercash constructor to this: > > public CyberCash(CyberCashTransActionIF transaction) { } > > My question is: Is this a hack? > > An interface that just extends 2 other interfaces just to combine them into a > nice "package" seem wrong to me OO desing side, but my old C-hack side says it > works, so do it. > > Futher design details show that there are some object that just do > CreditPaymentInformation and other classes that just do CyberCashResponse, but a > majorit of them do both. > > > > > -- > Bob Tanner | Phone : (952)943-8700 > http://www.mn-linux.org | Fax : (952)943-8500 > Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 > > _______________________________________________ > tclug-devel mailing list > tclug-devel@mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel From nobody170 at yahoo.com Fri Jul 13 11:29:41 2001 From: nobody170 at yahoo.com (Bill Gladen) Date: Mon Jan 17 14:29:23 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? In-Reply-To: <007201c10bb9$3e88e9e0$0300000a@anelginanalas> Message-ID: <20010713162941.23578.qmail@web10008.mail.yahoo.com> Well, I just can't resist weighing in on some of these, so here I go. Responses interwoven --- Mike Bresnahan wrote: > Why not just pass two arguments to the constructor - request and > response? > That would model how the Servlet API is designed. A very valid point. Basically a decision should be made as to wether the resulting combination forms a logical union > By the way, my personal taste is to never design an interface or > class that > has nothing but get()/set() functions. I don't think such a class > has > enough interesting behavior to be a class of its own. You can easily > factor > out the reusable behavior of such a class and all bizillion other > similar > classes into a interface like this: > > interface Tuple { > public Object getValue( String Key); > public void putValue( String Key, Object value); > } AAHHHH!!! It Hurtsess usss!!! Makesss it go awayyyy. There are often valid reasons to provide a class that is primarily getters and setters. One of the easiest to defend is data integrity. If your class must have values for ((A and B) or (B and C) or D) at any given time for it to be a valid instance, you can provide constructors that force you to pass enough values in, and put checks in the setters that prevent you from setting something to null incorrectly. Another BigThing you lose is clarity. The above will work and may be easier to write, but figuring out what it does later is a real pain if you have a bunch of Tuple s floating around in your code, rather than an Account, a CommissionModel, and three LineItem s. > Here's a couple quick examples that illustrate the advantages of this > design: > > - you only need to write one toString() function, not a bizillion > - you only need to write one function to insert, update, or delete > this > tuple from a RDBMS, not a bizillion > > Thus the design eliminates a lot of redundant code and therefore > reduces > bugs, complexity, compile time, etc. However it comes at the cost of > dynamic typing vs static typing. It may reduce the code, bugs, complexity, and compile time of this code, but it will increase the complexity of using the code, thereby increasing the downstream bugs, and the compile time you reduced will be time you have to spend by hand later finding out that you typed: theTuple.set( "weight", new Integer( weight ) ); in one class, and retrieved the value with either int weight = ((Integer)theTuple.get( "wieght" )).intValue(); or String weight = (String)theTuple.get( "wieght" ); in another class. The compiler would have found either type of error much more quickly than you will. > If I didn't want to pay the costs of dynamic typing and really really > wanted > it to be statically typed, then I would just create a "struct" like > class to > be a convenient way of grouping the data elements together. > > public class CreditPaymentInformationIF { > public String orderNumber; > //... > } > > You may stop and say, "But its not encapsulated!". But I will > counter with, > "Yes it is, but the encapsulation barrier is the function that > returns the > instance of the class." That function is the black box where all the > interesting behavior happens. The above class is simply the > resulting data. I would only agree with this if the data were all uncontrolled and always will remain so. If you need any sort of control of any of the data, or_even_if_you_may_in_the_future, you should encapsulate. Otherwise, to change it later, you will break all of the using classes that rely on the data being public. > One other thing... it seems possibly bad design to be passing the > request > and response to a Thread constructor for two reasons. > > - Creating threads and handling requests are conceptually two > different > things - one is a performance optimization and the other is a > business > process. > - Creating a thread for every request could be a performance problem I agree with this. Creating a Thread is really expensive. Actually, creating a Thread object is as cheap as any other object, but calling start() is very expensive. You probably want to give the CyberCache object some other method like 'processRequest' rather than 'run', and then create some Thread s that service the requests one after another. > You might be better off seperating the two concepts and also using a > thread > pool and Producer-Consumer pattern to handle incoming requests. If > you do > it right, the request handler could be generic enough to be reuable > by your > next server application. Be really carefull with patterns. They are generally over-used in my opinion. > You asked for my opinion and you got it. :) insert evil grin > Mike > ----- Original Message ----- > From: "Bob Tanner" > To: > Sent: Friday, July 13, 2001 1:46 AM > Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? > > > > Well, smack me and call me silly. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From mike at fruitioninc.com Fri Jul 13 15:22:42 2001 From: mike at fruitioninc.com (Mike Bresnahan) Date: Mon Jan 17 14:29:23 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? References: <20010713162941.23578.qmail@web10008.mail.yahoo.com> Message-ID: <009901c10bd9$91fe1080$0300000a@anelginanalas> If you feel there is value in attaching names to your tuples, then you can always do this: class MyTupleName extends Tuple { } Or more simply in C, C++, or CORBA IDL: typedef Tuple MyTupleName; I agree that there is a cost when to use dynamic typing. I illuded to it and you elaborated on it. However, Java makes this trade-off all over the place and it always will until they add the equivalent of C++ templates (e.g. the container classes). Additionally, in the type of applications I have written over the past 7 years, the source and destination of the data is dynamically typed. For example, the source and/or destination is often a RDBMS and the interface to the RDBMS (JDBC) is dynamically typed. Thus using static typing does not save you as much as you might want. Concerning the data validation logic you mentioned. I agree, the simple Tuple class I described does not support this. However, you could conceieve of one that did. Additionally, in my experience, 90% of the data elements in a given tuple do not have any business logic associated with them. To the application they are just plain old data going from one location to another - perhaps to the display monitor or to a RDBMS. As time passes and requirments change, elements get added, change type, or get removed, but the application really doesn't give a hoot. A dynamically typed architecture makes it much easier to maintain this sort of thing. For example, Bob, is there business logic in your application that depends on the zip code existing and having particular datatype - i.e. a dependency? Assuming there is none, then why force your application to have such a dependency? Unnecessary dependencies are the bane of software quality. This is same agrument used to advocate data abstraction and the same mistake that caused the Y2K problem. Note that I do believe in static typing for elements that do have a lot of application logic attached to them. Why do you think patterns are over used, Bill? My opinion is that they are way _under_ used. In any case, the Producer-Consumer pattern is the perfect fit for the problem and the one I've seen used in many similar servers. The idea is there you have a single request handler thread that does nothing but recieve requests and put them on a queue and a pool of worker threads taking requests of the queue and processing them. You may also want a response handler thread to deliver the responses asynchronisly. Mike ----- Original Message ----- From: "Bill Gladen" To: "Mike Bresnahan" ; Sent: Friday, July 13, 2001 9:29 AM Subject: Re: [TCLUG-DEVEL] Java Interfaces and multi-extends? > Well, I just can't resist weighing in on some of these, so here I go. > > Responses interwoven > > --- Mike Bresnahan wrote: > > Why not just pass two arguments to the constructor - request and > > response? > > That would model how the Servlet API is designed. > > A very valid point. Basically a decision should be made as to wether > the resulting combination forms a logical union > > > > By the way, my personal taste is to never design an interface or > > class that > > has nothing but get()/set() functions. I don't think such a class > > has > > enough interesting behavior to be a class of its own. You can easily > > factor > > out the reusable behavior of such a class and all bizillion other > > similar > > classes into a interface like this: > > > > interface Tuple { > > public Object getValue( String Key); > > public void putValue( String Key, Object value); > > } > > AAHHHH!!! It Hurtsess usss!!! Makesss it go awayyyy. > > There are often valid reasons to provide a class that is primarily > getters and setters. One of the easiest to defend is data integrity. > If your class must have values for ((A and B) or (B and C) or D) at any > given time for it to be a valid instance, you can provide constructors > that force you to pass enough values in, and put checks in the setters > that prevent you from setting something to null incorrectly. > > Another BigThing you lose is clarity. The above will work and may be > easier to write, but figuring out what it does later is a real pain if > you have a bunch of Tuple s floating around in your code, rather than > an Account, a CommissionModel, and three LineItem s. > > > > Here's a couple quick examples that illustrate the advantages of this > > design: > > > > - you only need to write one toString() function, not a bizillion > > - you only need to write one function to insert, update, or delete > > this > > tuple from a RDBMS, not a bizillion > > > > Thus the design eliminates a lot of redundant code and therefore > > reduces > > bugs, complexity, compile time, etc. However it comes at the cost of > > dynamic typing vs static typing. > > It may reduce the code, bugs, complexity, and compile time of this > code, but it will increase the complexity of using the code, thereby > increasing the downstream bugs, and the compile time you reduced will > be time you have to spend by hand later finding out that you typed: > > theTuple.set( "weight", new Integer( weight ) ); > > in one class, and retrieved the value with either > > int weight = ((Integer)theTuple.get( "wieght" )).intValue(); > or > String weight = (String)theTuple.get( "wieght" ); > > in another class. The compiler would have found either type of error > much more quickly than you will. > > > > > If I didn't want to pay the costs of dynamic typing and really really > > wanted > > it to be statically typed, then I would just create a "struct" like > > class to > > be a convenient way of grouping the data elements together. > > > > public class CreditPaymentInformationIF { > > public String orderNumber; > > //... > > } > > > > You may stop and say, "But its not encapsulated!". But I will > > counter with, > > "Yes it is, but the encapsulation barrier is the function that > > returns the > > instance of the class." That function is the black box where all the > > interesting behavior happens. The above class is simply the > > resulting data. > > I would only agree with this if the data were all uncontrolled and > always will remain so. If you need any sort of control of any of the > data, or_even_if_you_may_in_the_future, you should encapsulate. > Otherwise, to change it later, you will break all of the using classes > that rely on the data being public. > > > > One other thing... it seems possibly bad design to be passing the > > request > > and response to a Thread constructor for two reasons. > > > > - Creating threads and handling requests are conceptually two > > different > > things - one is a performance optimization and the other is a > > business > > process. > > - Creating a thread for every request could be a performance problem > > I agree with this. Creating a Thread is really expensive. Actually, > creating a Thread object is as cheap as any other object, but calling > start() is very expensive. You probably want to give the CyberCache > object some other method like 'processRequest' rather than 'run', and > then create some Thread s that service the requests one after another. > > > > You might be better off seperating the two concepts and also using a > > thread > > pool and Producer-Consumer pattern to handle incoming requests. If > > you do > > it right, the request handler could be generic enough to be reuable > > by your > > next server application. > > Be really carefull with patterns. They are generally over-used in my > opinion. > > > > You asked for my opinion and you got it. :) > > insert evil grin > > > > Mike > > ----- Original Message ----- > > From: "Bob Tanner" > > To: > > Sent: Friday, July 13, 2001 1:46 AM > > Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? > > > > > > > Well, smack me and call me silly. > > > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail > http://personal.mail.yahoo.com/ From nobody170 at yahoo.com Mon Jul 16 09:14:58 2001 From: nobody170 at yahoo.com (Bill Gladen) Date: Mon Jan 17 14:29:23 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? In-Reply-To: <009901c10bd9$91fe1080$0300000a@anelginanalas> Message-ID: <20010716141458.6045.qmail@web10001.mail.yahoo.com> A real discussion! woo hoo! Mike, you make some very valid points. I think I should preface this with a disclaimer to everyone else reading this. All points presented by both sides of the discussion are correct. Most of the work of designing a system is in choosing one of many ways to do something, and making tradeoffs between various goals of programming. So here we go. I don't like empty class extensions. It doesn't give you anything but confusion, unless you provide the base name within the sub-class name. Just name your variables. HashMap customerDataHashmap = ... rather than CustomerData extends HashMap{} ... CustomerData myCustomerData = ... Otherwise, when someone else is trying to read you code later, they come across a CustomerData type and have to keep track of the fact (once they figure it out) that it's just a HashMap. On to the dynamic typing issue. Yes, the interface to the RDBMS is dynamically typed, but the data in it generally is not. This is a case of dynamic typing being *unavoidable*. To implement an interface to a system that stores arbitrary data, you need your interface to handle arbitrary data types. Therefore, they (correctly) made the tradeoff to dynamic typing. If you do not *need* to handle arbitrary data, you shouldn't. This is the same for the container classes; they need to handle arbitrary data, so they are dynamically typed. Data validation. Yes, you could make a Tuple class that validated it's data, but it would have to break the principle of abstraction to do so. You would have to check what was going in (the key probably) to see if you wanted to validate the field or not. This breaks abstraction because the key is no longer a generic and arbitrary key object, but something to be checked on input, and you would have to document in the interface every 'special case' key, and what it's requirements are. If you have more than one validated field, this will get really ugly very quickly. I agree that you don't want to put in data constraints that are not necessary. If all you are doing is shuttling data from a RDBMS to a screen and back, you can probably get away with storing a bunch of strings and displaying generic objects. Next month, however, when marketing decides they want to integrate with the mailing list and print address labels for some reason, you have data integrity issues. Then, next year when a law gets passed that you have to check all mailings against a centralized government DB server, you could run into real problems. I'm not saying that you should enforce all of the data integrity you can possibly think of (that way lies madness), but you should have the ability to put it in later with minimal impact. Design Patterns. I suppose I should say that they are over used in *some* places. Heh; this is probably my most unpopular opinion. With the exception, perhapse of my opinion on EJBs. Design Patterns (ala gang-of-four book) are all the rage right now. They are useful solutions to know, and solve some sticky problems if you happen to have those problems. Every single one of them, however breaks the KISS principle. If you read the book, it actually states this right in the beginning, and warns against using them if you don't need them. Notice that I didn't say don't use them, just be careful. If you overuse them you end up with a system that is too complex to use and maintain. You can use a producer-consumer pattern, but you could also use something simple like: // note that I'm leaving out the synchronization and error handling, // they're almost, but not quite, trivial ... for( i = 0; i < NUMBER_OF_PROCESSING_THREADS; i++ ){ Thread t = new Thread( new Runnable(){ public void run(){ while( true ){ if( jobQueue.hasNext() ){ ((Job)jobQueue.next()).runJob(); }else{ sleep( SLEEP_TIME ); } } } } ); t.setDaemon( true ); // VERY IMPORTANT!! t.start(); } A couple things. Note that you could use Runnable instead of Job, and then combine processing of different tasks, but this could confuse people, because they tend to associate Runnable with separate Thread objects. Also, you could use a wait()/notify() process rather than check and sleep. It would be cleaner, but at that point you probably should break the inner class out into it's own file, need to pair it with the queue, and then it's harder to show everything in an e-mail. :-) This is just the KISS principle in action, so I kept it small. }:-> Bill --- Mike Bresnahan wrote: > If you feel there is value in attaching names to your tuples, then > you can > always do this: > > class MyTupleName extends Tuple { } > > Or more simply in C, C++, or CORBA IDL: > > typedef Tuple MyTupleName; > > I agree that there is a cost when to use dynamic typing. I illuded > to it > and you elaborated on it. However, Java makes this trade-off all > over the > place and it always will until they add the equivalent of C++ > templates > (e.g. the container classes). Additionally, in the type of > applications I > have written over the past 7 years, the source and destination of the > data > is dynamically typed. For example, the source and/or destination is > often a > RDBMS and the interface to the RDBMS (JDBC) is dynamically typed. > Thus > using static typing does not save you as much as you might want. > > Concerning the data validation logic you mentioned. I agree, the > simple > Tuple class I described does not support this. However, you could > conceieve > of one that did. Additionally, in my experience, 90% of the data > elements > in a given tuple do not have any business logic associated with them. > To > the application they are just plain old data going from one location > to > another - perhaps to the display monitor or to a RDBMS. As time > passes and > requirments change, elements get added, change type, or get removed, > but the > application really doesn't give a hoot. A dynamically typed > architecture > makes it much easier to maintain this sort of thing. For example, > Bob, is > there business logic in your application that depends on the zip > code > existing and having particular datatype - i.e. a dependency? > Assuming there > is none, then why force your application to have such a dependency? > Unnecessary dependencies are the bane of software quality. This is > same > agrument used to advocate data abstraction and the same mistake that > caused > the Y2K problem. > > Note that I do believe in static typing for elements that do have a > lot of > application logic attached to them. > > Why do you think patterns are over used, Bill? My opinion is that > they are > way _under_ used. In any case, the Producer-Consumer pattern is the > perfect > fit for the problem and the one I've seen used in many similar > servers. The > idea is there you have a single request handler thread that does > nothing but > recieve requests and put them on a queue and a pool of worker threads > taking > requests of the queue and processing them. You may also want a > response > handler thread to deliver the responses asynchronisly. > > Mike > ----- Original Message ----- > From: "Bill Gladen" > To: "Mike Bresnahan" ; > > Sent: Friday, July 13, 2001 9:29 AM > Subject: Re: [TCLUG-DEVEL] Java Interfaces and multi-extends? > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From mike at fruitioninc.com Mon Jul 16 14:26:52 2001 From: mike at fruitioninc.com (Mike Bresnahan) Date: Mon Jan 17 14:29:23 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? References: <20010716141458.6045.qmail@web10001.mail.yahoo.com> Message-ID: <01ae01c10e2d$44b82300$0300000a@anelginanalas> From: "Bill Gladen" To: Sent: Monday, July 16, 2001 7:14 AM Subject: Re: [TCLUG-DEVEL] Java Interfaces and multi-extends? > I think I should preface this with a disclaimer to everyone else > reading this. All points presented by both sides of the discussion are > correct. Most of the work of designing a system is in choosing one of > many ways to do something, and making tradeoffs between various goals > of programming. Both opinions may be correct, but mine is the most correct. ;) > Yes, the interface to the RDBMS is dynamically typed, but the data in > it generally is not. This is a case of dynamic typing being > *unavoidable*. To implement an interface to a system that stores > arbitrary data, you need your interface to handle arbitrary data types. > Therefore, they (correctly) made the tradeoff to dynamic typing. If > you do not *need* to handle arbitrary data, you shouldn't. This is the > same for the container classes; they need to handle arbitrary data, so > they are dynamically typed. My point is that by considering the data to be dynamically typed, you can write code that is more general. For example, you can write one toString() function instead of one for every data holder class. To illustrate this further, see the following code: // Multiple statically typed data holder classes design class DataHolder1 { private String a; private int b; public String getA() { return a; } public int getB() { return b; } public String toString() { return "{a=" + a + ",b=" + b + "}"; } } class DataHolder2 { private String a; private double b; private java.util.Date c; public String getA() { return a; } public int getB() { return b; } public java.util.Date getC() { return c; } public String toString() { return "{a=" + a + ",b=" + b + ",c=" + c + "}"; } } class DataHolder3 { // ... } class DataHolder4 { // ... } // ... on and on and on... until DataHolderBizillion // Single dynamically typed holder class design class Tuple { private java.util.Hashtable map; public Object get( String key) { return map.get( key); } public void put( String key, Object value) { map.put( key,value); } public String toString() { StringBuffer buffer = new StringBuffer(); buffer.append("{"); java.util.Enumeration enum = map.keys(); while( enum.hasMoreElements()) { String key = (String)enum.nextElement(); Object value = map.get( key); buffer.append( key); buffer.append("="); buffer.append( value); buffer.append(","); } buffer.append("}"); return buffer.toString(); } As a excercise for the reader, make changes to each implementation to make toString() use '[' intead of '{'. When you're done, tell me which design you spent the most time making the changes to. This is just a simple example. A more complex example is a function that inserts the data into a given table in a given database. > Data validation. > > Yes, you could make a Tuple class that validated it's data, but it > would have to break the principle of abstraction to do so. You would > have to check what was going in (the key probably) to see if you wanted > to validate the field or not. This breaks abstraction because the key > is no longer a generic and arbitrary key object, but something to be > checked on input, and you would have to document in the interface every > 'special case' key, and what it's requirements are. If you have more > than one validated field, this will get really ugly very quickly. Allow me to change my mind. I don't think I would put validations in a tuple class. Tuple is simply a data holder, not a data processor. I would put the data validation in the data processing classes. > Design Patterns. > > I suppose I should say that they are over used in *some* places. > > Heh; this is probably my most unpopular opinion. With the exception, > perhapse of my opinion on EJBs. Design Patterns (ala gang-of-four > book) are all the rage right now. They are useful solutions to know, > and solve some sticky problems if you happen to have those problems. > > Every single one of them, however breaks the KISS principle. If you > read the book, it actually states this right in the beginning, and > warns against using them if you don't need them. > > Notice that I didn't say don't use them, just be careful. If you > overuse them you end up with a system that is too complex to use and > maintain. What is the KISS principle - Keep It Super Simple? I don't follow you here. Why do you think patterns produce overly complex solutions? The idea is that they are the best of breed of solutions, no? If there is a better way to do something then perhaps that way should be a pattern! What is your opinion of EJB? My opinion is that the entity bean model is misguided for the same reasons we have been discussing here. I think it breeds bizillions of boring data holder classes along with bizillions of lines of redundant code. I'm not strong with this opinion yet, because I have not actually done any EJB development. > You can use a producer-consumer pattern, but you could also use > something simple like: > > // note that I'm leaving out the synchronization and error handling, > // they're almost, but not quite, trivial > ... > for( i = 0; i < NUMBER_OF_PROCESSING_THREADS; i++ ){ > Thread t = new Thread( new Runnable(){ > public void run(){ > while( true ){ > if( jobQueue.hasNext() ){ > ((Job)jobQueue.next()).runJob(); > }else{ > sleep( SLEEP_TIME ); > } > } > } > } ); > t.setDaemon( true ); // VERY IMPORTANT!! > t.start(); > } I'm confused. This IS the producer consumer pattern. Well ok, its part of it. You haven't shown the rest of the code, e.g. the implemenation of jobQueue.hasNext() and you haven't used a good performing sychronization mechanism. > Also, you could use a wait()/notify() process rather than check and > sleep. It would be cleaner, but at that point you probably should > break the inner class out into it's own file, need to pair it with the > queue, and then it's harder to show everything in an e-mail. :-) This > is just the KISS principle in action, so I kept it small. Cleaner yes and also a better performer and better neighbor. The sleep() design will use up CPU when the application is idle. A design should be simple, but not TOO simple. I think I may be missing your logic with respest to the KISS principle and design patterns. Mike From mike at fruitioninc.com Mon Jul 16 15:29:19 2001 From: mike at fruitioninc.com (Mike Bresnahan) Date: Mon Jan 17 14:29:23 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? References: <20010716141458.6045.qmail@web10001.mail.yahoo.com> Message-ID: <01d801c10e35$fd81ead0$0300000a@anelginanalas> > Yes, the interface to the RDBMS is dynamically typed, but the data in > it generally is not. This is a case of dynamic typing being > *unavoidable*. To implement an interface to a system that stores > arbitrary data, you need your interface to handle arbitrary data types. > Therefore, they (correctly) made the tradeoff to dynamic typing. If > you do not *need* to handle arbitrary data, you shouldn't. This is the > same for the container classes; they need to handle arbitrary data, so > they are dynamically typed. One other note... the container classes in Java did not need to be dynamically typed. One could have been implemented for element type, e.g. vector, vector, etc. The designers of Java simply made a trade-off in favor of dynamic typing. Mike From nobody170 at yahoo.com Tue Jul 17 08:23:04 2001 From: nobody170 at yahoo.com (Bill Gladen) Date: Mon Jan 17 14:29:23 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? In-Reply-To: <01ae01c10e2d$44b82300$0300000a@anelginanalas> Message-ID: <20010717132304.49566.qmail@web10005.mail.yahoo.com> Okay, today's preface will be that I'm grumpy. On that note, I shall withdraw yesterday's preface and state that He's flat out wrong. :-) First, a toString() is one of the most trivial things you can put in a class, and generally not considered very important unless you need to debug your stuff. Try writing a clone() (a deep clone, no cheating) or implement the serializable interface (again with deep serialization) on the Tuple class. As for data validation, and not putting any in, why do you even have a Tuple class? If there's no validation, and it's just a placeholder for data, then just use a HashMap. If you need other functionality, write a utility class (it can even be completely static) that has a method to return a string from a HashMap. KISS = Keep It Simple, Stupid. As for the synchronization and implementation of jobQueue.hasNext(), here is the revised code. Note the lack of reinvented wheels. ... LinkedList jobQueue = new LinkedList(); for( i = 0; i < NUMBER_OF_PROCESSING_THREADS; i++ ){ Thread t = new Thread( new Runnable(){ public void run(){ Job job; while( true ){ job = null; synchronized( jobQueue ){ if( ! jobQueue.isEmpty() ){ job = (Job)jobQueue.removeFirst(); } } if( null != job ){ try{ job.runJob(); }catch( Throwable t ){ // handle this. } }else{ try{ sleep( SLEEP_TIME ); }catch( InterruptedException ie ){ } } } } } ); t.setDaemon( true ); // VERY IMPORTANT!! t.start(); } That's all off the cuff, so if there are syntax errors, don't nit-pick. As for the sleep vs. wait/notify, yes this will use cycles, but it will probably be about 20 instructions per idle cycle (it would be about 3, but synchronization is expensive), which translates into less than .1 millisecond on today's processors. If you are sleeping for 1 second, .01% is not enough to worry about. This way, the synchronization, processing, and run logic is in one place. If you implemented the classic producer/consumer pattern, you'd probably have 3 extra classes, and if you were using a pooled resource pattern for the Threads, that would be another 2 or 3 classes, and if you were using the Factory pattern to create the threads (so you could change the subclass of Thread or Runnable you used without changing any code) that would be ANOTHER 2 classes AND a properties file... If you think I'm just going off the deep end here, I've seen this kind of code. Using it is a serious nightmare. Bill --- Mike Bresnahan wrote: > From: "Bill Gladen" > To: > Sent: Monday, July 16, 2001 7:14 AM > Subject: Re: [TCLUG-DEVEL] Java Interfaces and multi-extends? > > > > I think I should preface this with a disclaimer to everyone else > > reading this. All points presented by both sides of the discussion > are > > correct. Most of the work of designing a system is in choosing one > of > > many ways to do something, and making tradeoffs between various > goals > > of programming. > > Both opinions may be correct, but mine is the most correct. ;) > > > Yes, the interface to the RDBMS is dynamically typed, but the data > in > > it generally is not. This is a case of dynamic typing being > > *unavoidable*. To implement an interface to a system that stores > > arbitrary data, you need your interface to handle arbitrary data > types. > > Therefore, they (correctly) made the tradeoff to dynamic typing. > If > > you do not *need* to handle arbitrary data, you shouldn't. This is > the > > same for the container classes; they need to handle arbitrary data, > so > > they are dynamically typed. > > My point is that by considering the data to be dynamically typed, you > can > write code that is more general. For example, you can write one > toString() > function instead of one for every data holder class. To illustrate > this > further, see the following code: > > // Multiple statically typed data holder classes design > > class DataHolder1 { > private String a; > private int b; > public String getA() { return a; } > public int getB() { return b; } > public String toString() { return "{a=" + a + ",b=" + b + "}"; } > } > > class DataHolder2 { > private String a; > private double b; > private java.util.Date c; > public String getA() { return a; } > public int getB() { return b; } > public java.util.Date getC() { return c; } > public String toString() { return "{a=" + a + ",b=" + b + ",c=" + > c + > "}"; } > } > > class DataHolder3 { > // ... > } > > class DataHolder4 { > // ... > } > > // ... on and on and on... until DataHolderBizillion > > // Single dynamically typed holder class design > > class Tuple { > private java.util.Hashtable map; > public Object get( String key) { > return map.get( key); > } > public void put( String key, Object value) { > map.put( key,value); > } > public String toString() { > StringBuffer buffer = new StringBuffer(); > buffer.append("{"); > java.util.Enumeration enum = map.keys(); > while( enum.hasMoreElements()) { > String key = (String)enum.nextElement(); > Object value = map.get( key); > buffer.append( key); > buffer.append("="); > buffer.append( value); > buffer.append(","); > } > buffer.append("}"); > return buffer.toString(); > } > > As a excercise for the reader, make changes to each implementation to > make > toString() use '[' intead of '{'. When you're done, tell me which > design > you spent the most time making the changes to. > > This is just a simple example. A more complex example is a function > that > inserts the data into a given table in a given database. > > > Data validation. > > > > Yes, you could make a Tuple class that validated it's data, but it > > would have to break the principle of abstraction to do so. You > would > > have to check what was going in (the key probably) to see if you > wanted > > to validate the field or not. This breaks abstraction because the > key > > is no longer a generic and arbitrary key object, but something to > be > > checked on input, and you would have to document in the interface > every > > 'special case' key, and what it's requirements are. If you have > more > > than one validated field, this will get really ugly very quickly. > > Allow me to change my mind. I don't think I would put validations in > a > tuple class. Tuple is simply a data holder, not a data processor. I > would > put the data validation in the data processing classes. > > > Design Patterns. > > > > I suppose I should say that they are over used in *some* places. > > > > Heh; this is probably my most unpopular opinion. With the > exception, > > perhapse of my opinion on EJBs. Design Patterns (ala gang-of-four > > book) are all the rage right now. They are useful solutions to > know, > > and solve some sticky problems if you happen to have those > problems. > > > > Every single one of them, however breaks the KISS principle. If > you > > read the book, it actually states this right in the beginning, and > > warns against using them if you don't need them. > > > > Notice that I didn't say don't use them, just be careful. If you > > overuse them you end up with a system that is too complex to use > and > > maintain. > > What is the KISS principle - Keep It Super Simple? > > I don't follow you here. Why do you think patterns produce overly > complex > solutions? The idea is that they are the best of breed of solutions, > no? > If there is a better way to do something then perhaps that way should > be a > pattern! > > What is your opinion of EJB? My opinion is that the entity bean > model is > misguided for the same reasons we have been discussing here. I think > it > breeds bizillions of boring data holder classes along with bizillions > of > lines of redundant code. I'm not strong with this opinion yet, > because I > have not actually done any EJB development. > > > You can use a producer-consumer pattern, but you could also use > > something simple like: > > > > // note that I'm leaving out the synchronization and error > handling, > > // they're almost, but not quite, trivial > > ... > > for( i = 0; i < NUMBER_OF_PROCESSING_THREADS; i++ ){ > > Thread t = new Thread( new Runnable(){ > > public void run(){ > > while( true ){ > > if( jobQueue.hasNext() ){ > > ((Job)jobQueue.next()).runJob(); > > }else{ > > sleep( SLEEP_TIME ); > > } > > } > > } > > } ); > > t.setDaemon( true ); // VERY IMPORTANT!! > > t.start(); > > } > > I'm confused. This IS the producer consumer pattern. Well ok, its > part of > it. You haven't shown the rest of the code, e.g. the implemenation > of > jobQueue.hasNext() and you haven't used a good performing > sychronization > === message truncated === __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From mike at fruitioninc.com Tue Jul 17 12:45:29 2001 From: mike at fruitioninc.com (Mike Bresnahan) Date: Mon Jan 17 14:29:23 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? References: <20010717132304.49566.qmail@web10005.mail.yahoo.com> Message-ID: <024101c10ee8$452308d0$0300000a@anelginanalas> We may end up having to agree to disagree. Heh Let me start with a disclaimer. I have been guilty more than once of creating overly complex solutions as a result of my passionate pursuit of elegant, generic, and beautiful code. I think it is the mathematician/physitist in me. I'm always seeking to make my code more and more general and semmetric much like mathematicians and physiticts are always seeking to find the underlying thereom or the grand unified theory. So I understand first hand your concerns about unnecessary code complexity. However, I do not feel I am guilty in the current context. I create a new class called Tuple so that I can change the implementation later without effecting client code - basic data abstraction. I also find that the name more clearly describes the class's role. Additionally, I may want to add more features. For example, I may want the tuple to maintain order of the elements. java.sql.ResultSet does this. You can retrieve a column via its name or its index. Hashtable does not allow this. I feel the producer-consumer pattern is not nearly as complex as you're making it out to be. Here's some sample code off the top of my head based on that found in Patterns in Java. public class Producer implements Runnable { private Queue queue; public void run() { Thingy thingy = getThingy(); queue.push( thingy); } } public class Consumer implements Runnable { private Queue queue; public run() { Thingy thingy = queue.pull(); } } public class Queue { private java.util.LinkedList list = new java.util.LinkedList(); public synchronized void push( Thingy thingy) { list.add( thingy); notify(); } public synchronized Thingy pull() { if( list.size() == 0) { try { wait(); } catch( InterrruptedException ex) { } } return (Thingy)list.removeFirst(); } } I'd also like to make the point that there is more to software quality than source code simplicity. In fact, the most important software quality criteria have nothing to do with source code, rather they have to do with user satisfaction. User's really don't care how simple, beautiful, or maintainable your code is. They only care how well it performs the work they ask of it. By not using the producer-consumer combined with a thread pool you seem to favor code simplicity over user satisfaction. I also believe that code simplicity is not always the road to maintainability. For instance, hard coding the number of worker threads into the application may be simple, but it is a maintainence headache. People supporting the software in the future will have to make code changes, do testing, and do a rollout simply to do some simple performance tuning. Hard coding anything like that is a big no-no in my book. I've had to rewrite more than once code that used polling instead of proper wait/notify semantics, because of the performance problem it was causing. I think 20 instructions per poll is an overly conservative estimate. Can Java get anything done in 20 cyles? Additionally, if you plan to run this application on a server shared by other applications you simply aren't being a good neighbor by wasting precious cpu cycles. Even with today's 1Ghz processors, cpu cycles are not a renewable resource. Perhaps you should reconsider your refusal to sign the Kioto Protocol, Mr Bush. Mike ----- Original Message ----- From: "Bill Gladen" To: Sent: Tuesday, July 17, 2001 6:23 AM Subject: Re: [TCLUG-DEVEL] Java Interfaces and multi-extends? > Okay, today's preface will be that I'm grumpy. > On that note, I shall withdraw yesterday's preface and state that He's > flat out wrong. :-) > > First, a toString() is one of the most trivial things you can put in a > class, and generally not considered very important unless you need to > debug your stuff. Try writing a clone() (a deep clone, no cheating) or > implement the serializable interface (again with deep serialization) on > the Tuple class. > > As for data validation, and not putting any in, why do you even have a > Tuple class? If there's no validation, and it's just a placeholder for > data, then just use a HashMap. If you need other functionality, write > a utility class (it can even be completely static) that has a method to > return a string from a HashMap. > > KISS = Keep It Simple, Stupid. > > As for the synchronization and implementation of jobQueue.hasNext(), > here is the revised code. Note the lack of reinvented wheels. > > ... > LinkedList jobQueue = new LinkedList(); > for( i = 0; i < NUMBER_OF_PROCESSING_THREADS; i++ ){ > Thread t = new Thread( new Runnable(){ > public void run(){ > Job job; > while( true ){ > job = null; > synchronized( jobQueue ){ > if( ! jobQueue.isEmpty() ){ > job = (Job)jobQueue.removeFirst(); > } > } > if( null != job ){ > try{ > job.runJob(); > }catch( Throwable t ){ > // handle this. > } > }else{ > try{ > sleep( SLEEP_TIME ); > }catch( InterruptedException ie ){ > } > } > } > } > } ); > t.setDaemon( true ); // VERY IMPORTANT!! > t.start(); > } > > That's all off the cuff, so if there are syntax errors, don't nit-pick. > > As for the sleep vs. wait/notify, yes this will use cycles, but it will > probably be about 20 instructions per idle cycle (it would be about 3, > but synchronization is expensive), which translates into less than .1 > millisecond on today's processors. If you are sleeping for 1 second, > .01% is not enough to worry about. > > This way, the synchronization, processing, and run logic is in one > place. > > If you implemented the classic producer/consumer pattern, you'd > probably have 3 extra classes, and if you were using a pooled resource > pattern for the Threads, that would be another 2 or 3 classes, and if > you were using the Factory pattern to create the threads (so you could > change the subclass of Thread or Runnable you used without changing any > code) that would be ANOTHER 2 classes AND a properties file... > > If you think I'm just going off the deep end here, I've seen this kind > of code. Using it is a serious nightmare. > > Bill > > > > From mike at fruitioninc.com Tue Jul 17 13:00:29 2001 From: mike at fruitioninc.com (Mike Bresnahan) Date: Mon Jan 17 14:29:24 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? References: <20010717132304.49566.qmail@web10005.mail.yahoo.com> <024101c10ee8$452308d0$0300000a@anelginanalas> Message-ID: <026101c10eea$5da42860$0300000a@anelginanalas> Heh, boy did I mangle the word physicist - twice! ----- Original Message ----- From: "Mike Bresnahan" To: Sent: Tuesday, July 17, 2001 10:45 AM Subject: Re: [TCLUG-DEVEL] Java Interfaces and multi-extends? > We may end up having to agree to disagree. Heh > > Let me start with a disclaimer. I have been guilty more than once of > creating overly complex solutions as a result of my passionate pursuit of > elegant, generic, and beautiful code. I think it is the > mathematician/physitist in me. I'm always seeking to make my code more and > more general and semmetric much like mathematicians and physiticts are > always seeking to find the underlying thereom or the grand unified theory. > So I understand first hand your concerns about unnecessary code complexity. > However, I do not feel I am guilty in the current context. > > I create a new class called Tuple so that I can change the implementation > later without effecting client code - basic data abstraction. I also find > that the name more clearly describes the class's role. Additionally, I may > want to add more features. For example, I may want the tuple to maintain > order of the elements. java.sql.ResultSet does this. You can retrieve a > column via its name or its index. Hashtable does not allow this. > > I feel the producer-consumer pattern is not nearly as complex as you're > making it out to be. Here's some sample code off the top of my head based > on that found in Patterns in Java. > > public class Producer implements Runnable { > private Queue queue; > public void run() { > Thingy thingy = getThingy(); > queue.push( thingy); > } > } > > public class Consumer implements Runnable { > private Queue queue; > public run() { > Thingy thingy = queue.pull(); > } > } > > public class Queue { > private java.util.LinkedList list = new java.util.LinkedList(); > public synchronized void push( Thingy thingy) { > list.add( thingy); > notify(); > } > public synchronized Thingy pull() { > if( list.size() == 0) { > try { > wait(); > } > catch( InterrruptedException ex) { > } > } > return (Thingy)list.removeFirst(); > } > } > > I'd also like to make the point that there is more to software quality than > source code simplicity. In fact, the most important software quality > criteria have nothing to do with source code, rather they have to do with > user satisfaction. User's really don't care how simple, beautiful, or > maintainable your code is. They only care how well it performs the work > they ask of it. By not using the producer-consumer combined with a thread > pool you seem to favor code simplicity over user satisfaction. > > I also believe that code simplicity is not always the road to > maintainability. For instance, hard coding the number of worker threads > into the application may be simple, but it is a maintainence headache. > People supporting the software in the future will have to make code changes, > do testing, and do a rollout simply to do some simple performance tuning. > Hard coding anything like that is a big no-no in my book. > > I've had to rewrite more than once code that used polling instead of proper > wait/notify semantics, because of the performance problem it was causing. I > think 20 instructions per poll is an overly conservative estimate. Can Java > get anything done in 20 cyles? Additionally, if you plan to run this > application on a server shared by other applications you simply aren't being > a good neighbor by wasting precious cpu cycles. Even with today's 1Ghz > processors, cpu cycles are not a renewable resource. Perhaps you should > reconsider your refusal to sign the Kioto Protocol, Mr Bush. > > Mike > ----- Original Message ----- > From: "Bill Gladen" > To: > Sent: Tuesday, July 17, 2001 6:23 AM > Subject: Re: [TCLUG-DEVEL] Java Interfaces and multi-extends? > > > > Okay, today's preface will be that I'm grumpy. > > On that note, I shall withdraw yesterday's preface and state that He's > > flat out wrong. :-) > > > > First, a toString() is one of the most trivial things you can put in a > > class, and generally not considered very important unless you need to > > debug your stuff. Try writing a clone() (a deep clone, no cheating) or > > implement the serializable interface (again with deep serialization) on > > the Tuple class. > > > > As for data validation, and not putting any in, why do you even have a > > Tuple class? If there's no validation, and it's just a placeholder for > > data, then just use a HashMap. If you need other functionality, write > > a utility class (it can even be completely static) that has a method to > > return a string from a HashMap. > > > > KISS = Keep It Simple, Stupid. > > > > As for the synchronization and implementation of jobQueue.hasNext(), > > here is the revised code. Note the lack of reinvented wheels. > > > > ... > > LinkedList jobQueue = new LinkedList(); > > for( i = 0; i < NUMBER_OF_PROCESSING_THREADS; i++ ){ > > Thread t = new Thread( new Runnable(){ > > public void run(){ > > Job job; > > while( true ){ > > job = null; > > synchronized( jobQueue ){ > > if( ! jobQueue.isEmpty() ){ > > job = (Job)jobQueue.removeFirst(); > > } > > } > > if( null != job ){ > > try{ > > job.runJob(); > > }catch( Throwable t ){ > > // handle this. > > } > > }else{ > > try{ > > sleep( SLEEP_TIME ); > > }catch( InterruptedException ie ){ > > } > > } > > } > > } > > } ); > > t.setDaemon( true ); // VERY IMPORTANT!! > > t.start(); > > } > > > > That's all off the cuff, so if there are syntax errors, don't nit-pick. > > > > As for the sleep vs. wait/notify, yes this will use cycles, but it will > > probably be about 20 instructions per idle cycle (it would be about 3, > > but synchronization is expensive), which translates into less than .1 > > millisecond on today's processors. If you are sleeping for 1 second, > > .01% is not enough to worry about. > > > > This way, the synchronization, processing, and run logic is in one > > place. > > > > If you implemented the classic producer/consumer pattern, you'd > > probably have 3 extra classes, and if you were using a pooled resource > > pattern for the Threads, that would be another 2 or 3 classes, and if > > you were using the Factory pattern to create the threads (so you could > > change the subclass of Thread or Runnable you used without changing any > > code) that would be ANOTHER 2 classes AND a properties file... > > > > If you think I'm just going off the deep end here, I've seen this kind > > of code. Using it is a serious nightmare. > > > > Bill > > > > > > > > > > > _______________________________________________ > tclug-devel mailing list > tclug-devel@mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel From nobody170 at yahoo.com Tue Jul 17 12:33:51 2001 From: nobody170 at yahoo.com (Bill Gladen) Date: Mon Jan 17 14:29:24 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? In-Reply-To: <024101c10ee8$452308d0$0300000a@anelginanalas> Message-ID: <20010717173351.3967.qmail@web10005.mail.yahoo.com> Interwoven. (sorry) Once again, I'm not saying that design patterns are bad. In fact studying them can give you good insight into ways of doing things that really improve your code. Just don't use them every time you see something that vaguely resembles something they will solve. It's design pattern Over-Use that I dislike. --- Mike Bresnahan wrote: > We may end up having to agree to disagree. Heh I'm sure at least we'll disagree. Whether we agree to it or not is still up in the air. :) > > Let me start with a disclaimer. I have been guilty more than once of > creating overly complex solutions as a result of my passionate > pursuit of > elegant, generic, and beautiful code. I think it is the > mathematician/physitist in me. I'm always seeking to make my code > more and > more general and semmetric much like mathematicians and physiticts > are > always seeking to find the underlying thereom or the grand unified > theory. Fair enough, but even the most brilliant physicist uses Ag = -9.8 m/(s*s) for the accelleration due to gravity if they are not worried about how things will act on the moon, and don't think air friction will be that important. In this case, going after the generic just makes things worse. > So I understand first hand your concerns about unnecessary code > complexity. > However, I do not feel I am guilty in the current context. > > I create a new class called Tuple so that I can change the > implementation > later without effecting client code - basic data abstraction. I also > find > that the name more clearly describes the class's role. Additionally, > I may > want to add more features. For example, I may want the tuple to > maintain > order of the elements. java.sql.ResultSet does this. You can > retrieve a > column via its name or its index. Hashtable does not allow this. Fine. If you need that functionality, a Tuple could be a useful class. If you don't need it, you're over-complicating things in your search for simplicity. > I feel the producer-consumer pattern is not nearly as complex as > you're > making it out to be. Here's some sample code off the top of my head > based > on that found in Patterns in Java. > > public class Producer implements Runnable { > private Queue queue; > public void run() { > Thingy thingy = getThingy(); > queue.push( thingy); > } > } > > public class Consumer implements Runnable { > private Queue queue; > public run() { > Thingy thingy = queue.pull(); > } > } > > public class Queue { > private java.util.LinkedList list = new java.util.LinkedList(); > public synchronized void push( Thingy thingy) { > list.add( thingy); > notify(); > } > public synchronized Thingy pull() { > if( list.size() == 0) { > try { > wait(); > } > catch( InterrruptedException ex) { > } > } > return (Thingy)list.removeFirst(); > } > } Okay, those 3 skeletons look very simple. However it does show that you have 3 more classes, each of which will in the final version be quite a bit larger than what is shown above, each requiring another class to document, debug, and understand (for future maintainers). Also, what is written so far doesn't actually do much except wrap the ends of a Queue with wait/notify. You still have to make some threads, do something useful with the thingy, and start the execution. Not to mention deciding where to put the looping (parent Thread with a separate run() or in the run() s above) and how to control the termination of the process. Once you decide where to put these things, ask yourself how obvious will your decision be to the future maintainers? > I'd also like to make the point that there is more to software > quality than > source code simplicity. In fact, the most important software quality > criteria have nothing to do with source code, rather they have to do > with > user satisfaction. User's really don't care how simple, beautiful, > or > maintainable your code is. They only care how well it performs the > work > they ask of it. By not using the producer-consumer combined with a > thread > pool you seem to favor code simplicity over user satisfaction. Not quite true. Users will probably eventually care about the maintainability of your code, but that usually happens after you have been paid, so YOU might not care. The other thing they don't care about is your 'passionate pursuit of elegant, generic, and beautiful code.' What they care about is A) How much will it do? and B) How much will it cost? (maintainability is buried in B) Also, True Elegance and simplicity tend to go hand in hand; with the other hand, they hang onto maintainability. > I also believe that code simplicity is not always the road to > maintainability. For instance, hard coding the number of worker > threads > into the application may be simple, but it is a maintainence > headache. > People supporting the software in the future will have to make code > changes, > do testing, and do a rollout simply to do some simple performance > tuning. > Hard coding anything like that is a big no-no in my book. I completely agree, and you will note that I did not show any hard-coding of values. The ALL_CAPS_VARIABLES are often pulled from a properties file. Or, depending on the re-use potential of your class, they can be passed as a parameter by the using classes (which presumably get them from properties files). > I've had to rewrite more than once code that used polling instead of > proper > wait/notify semantics, because of the performance problem it was > causing. I > think 20 instructions per poll is an overly conservative estimate. > Can Java > get anything done in 20 cyles? It can get a lot done in 20 cycles. Run some tests with a modern VM sometime. But you're right. wait/notify is more proper, and that is why I mentioned it in the first place. However, most of the time when you have performance problems, it's because there is a straight spin, with no sleep time. And it would not be too difficult to modify the sleep loop code to wait properly. > Additionally, if you plan to run this > application on a server shared by other applications you simply > aren't being > a good neighbor by wasting precious cpu cycles. Even with today's > 1Ghz > processors, cpu cycles are not a renewable resource. Perhaps you > should > reconsider your refusal to sign the Kioto Protocol, Mr Bush. Again, that's why I mentioned it in the first place. > Mike > ----- Original Message ----- > From: "Bill Gladen" > To: > Sent: Tuesday, July 17, 2001 6:23 AM > Subject: Re: [TCLUG-DEVEL] Java Interfaces and multi-extends? > > > > Okay, today's preface will be that I'm grumpy. > > On that note, I shall withdraw yesterday's preface and state that > He's > > flat out wrong. :-) __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From mike at fruitioninc.com Tue Jul 17 14:57:37 2001 From: mike at fruitioninc.com (Mike Bresnahan) Date: Mon Jan 17 14:29:24 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? References: <20010717173351.3967.qmail@web10005.mail.yahoo.com> Message-ID: <02ec01c10efa$bac54d70$0300000a@anelginanalas> > Also, what is written so far doesn't actually do much except wrap the > ends of a Queue with wait/notify. You still have to make some threads, > do something useful with the thingy, and start the execution. Not to > mention deciding where to put the looping (parent Thread with a > separate run() or in the run() s above) and how to control the > termination of the process. Once you decide where to put these things, > ask yourself how obvious will your decision be to the future > maintainers? But that is one reason why one uses a pattern - so that others can more easily understand what you are doing and why. Any reader versed in the producer-consumer pattern will immediately have a good sense of the hows and whys simply by seeing the name "producer-consumer". Contrary to this, rolling your own solution causes the reader to start with nothing. No? I see patterns as a way to attack complexity not a way to increase it. Mike From nobody170 at yahoo.com Tue Jul 17 14:19:24 2001 From: nobody170 at yahoo.com (Bill Gladen) Date: Mon Jan 17 14:29:24 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? In-Reply-To: <02ec01c10efa$bac54d70$0300000a@anelginanalas> Message-ID: <20010717191924.20513.qmail@web10002.mail.yahoo.com> --- Mike Bresnahan wrote: > > Also, what is written so far doesn't actually do much except wrap > the > > ends of a Queue with wait/notify. You still have to make some > threads, > > do something useful with the thingy, and start the execution. Not > to > > mention deciding where to put the looping (parent Thread with a > > separate run() or in the run() s above) and how to control the > > termination of the process. Once you decide where to put these > things, > > ask yourself how obvious will your decision be to the future > > maintainers? > > But that is one reason why one uses a pattern - so that others can > more > easily understand what you are doing and why. Any reader versed in > the > producer-consumer pattern will immediately have a good sense of the > hows and > whys simply by seeing the name "producer-consumer". Contrary to > this, > rolling your own solution causes the reader to start with nothing. > No? > > I see patterns as a way to attack complexity not a way to increase > it. > > Mike > > I agree with this somewhat, but I will still stick to my guns about the 'be careful not to over-use patters' issue. The naming of patterns does tend to give people a cognitive anchor for dealing more easily with the over-all problem. But you can get most of that benefit just by giving your classes and variables good names. For instance, who would possibly be confused by a LinkedList called cyberCacheTransactionQueue? Or a method called startTransactionProcessingThreads( LinkedList inputQueue )? If you are getting the same thing done, and in much the same manner (start a bunch of threads, feed a queue from elsewhere, have the threads crunch away at the queue), then why put an artificial constraint on what classes to use? Particularly if most of the functionality you need is already sitting in front of you. There's no reason that a single class can't do both the producing and consuming, but if you are dead set on Implementing A Pattern Based Solution, that simply won't be something you will think of. All I'm saying about patterns is that they are not a silver bullet. Be careful out there. Bill __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From hopper at omnifarious.org Tue Jul 17 14:34:57 2001 From: hopper at omnifarious.org (Eric M. Hopper) Date: Mon Jan 17 14:29:24 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? In-Reply-To: <20010717173351.3967.qmail@web10005.mail.yahoo.com>; from nobody170@yahoo.com on Tue, Jul 17, 2001 at 10:33:51AM -0700 References: <024101c10ee8$452308d0$0300000a@anelginanalas> <20010717173351.3967.qmail@web10005.mail.yahoo.com> Message-ID: <20010717143457.A2106@omnifarious.org> On Tue, Jul 17, 2001 at 10:33:51AM -0700, Bill Gladen wrote: > Interwoven. (sorry) For the unenlightened, what significance does the word 'Interwoven' have in the discussion? Have fun (if at all possible), -- "It does me no injury for my neighbor to say there are twenty gods or no God. It neither picks my pocket nor breaks my leg." --- Thomas Jefferson "Go to Heaven for the climate, Hell for the company." -- Mark Twain -- Eric Hopper (hopper@omnifarious.org http://www.omnifarious.org/~hopper) -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/tclug-devel/attachments/20010717/c5214869/attachment.pgp From dutchman at uswest.net Tue Jul 17 14:42:27 2001 From: dutchman at uswest.net (Perry Hoekstra) Date: Mon Jan 17 14:29:24 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? References: <024101c10ee8$452308d0$0300000a@anelginanalas> <20010717173351.3967.qmail@web10005.mail.yahoo.com> <20010717143457.A2106@omnifarious.org> Message-ID: <3B549523.20504@uswest.net> Eric M. Hopper wrote: > On Tue, Jul 17, 2001 at 10:33:51AM -0700, Bill Gladen wrote: > >>Interwoven. (sorry) >> > > For the unenlightened, what significance does the word > 'Interwoven' have in the discussion? > > Have fun (if at all possible), > The response is weaved among the content of the email that is being replied to. -- Perry Hoekstra E-Commerce Architect Talent Software Services perry.hoekstra@talentemail.com From mike at fruitioninc.com Tue Jul 17 16:51:42 2001 From: mike at fruitioninc.com (Mike Bresnahan) Date: Mon Jan 17 14:29:24 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? References: <20010717191924.20513.qmail@web10002.mail.yahoo.com> Message-ID: <0d0c01c10f0a$aaafc4a0$0300000a@anelginanalas> > There's no reason that a single class can't do both the producing and > consuming, but if you are dead set on Implementing A > Pattern Based Solution, that simply won't be something you > will think of. > > All I'm saying about patterns is that they are not a silver bullet. Agreed. Yeah! I think the same about object orientation. I see people applying it blindly. There attitude is "if its OO then its good". They don't stop and analyze the design based on actual software quality criteria. OO is a tool to produce quality software. It is not a measure of software quality. The same goes for patterns. Creating a plethora of data holder classes is a great example of misapplied OO, but we've already been over that enough! Anyway, I still think a design based on producer-consumer for the cyber cash server is the way to go. Mike From hopper at omnifarious.org Tue Jul 17 14:55:57 2001 From: hopper at omnifarious.org (Eric M. Hopper) Date: Mon Jan 17 14:29:24 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? In-Reply-To: <3B549523.20504@uswest.net>; from dutchman@uswest.net on Tue, Jul 17, 2001 at 02:42:27PM -0500 References: <024101c10ee8$452308d0$0300000a@anelginanalas> <20010717173351.3967.qmail@web10005.mail.yahoo.com> <20010717143457.A2106@omnifarious.org> <3B549523.20504@uswest.net> Message-ID: <20010717145557.A2161@omnifarious.org> On Tue, Jul 17, 2001 at 02:42:27PM -0500, Perry Hoekstra wrote: > Eric M. Hopper wrote: > > > On Tue, Jul 17, 2001 at 10:33:51AM -0700, Bill Gladen wrote: > > > >>Interwoven. (sorry) > >> > > > > For the unenlightened, what significance does the word > > 'Interwoven' have in the discussion? > > > > Have fun (if at all possible), > > > > The response is weaved among the content of the email that is being > replied to. I realize this, but the word Interwoven is enver again mentioned after he first mentions it, and I'm curious as to why he used it. Have fun (if at all possible), -- "It does me no injury for my neighbor to say there are twenty gods or no God. It neither picks my pocket nor breaks my leg." --- Thomas Jefferson "Go to Heaven for the climate, Hell for the company." -- Mark Twain -- Eric Hopper (hopper@omnifarious.org http://www.omnifarious.org/~hopper) -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/tclug-devel/attachments/20010717/9c5e0ae6/attachment.pgp From hopper at omnifarious.org Tue Jul 17 15:06:47 2001 From: hopper at omnifarious.org (Eric M. Hopper) Date: Mon Jan 17 14:29:24 2005 Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends? In-Reply-To: <20010717145557.A2161@omnifarious.org>; from hopper@omnifarious.org on Tue, Jul 17, 2001 at 02:55:57PM -0500 References: <024101c10ee8$452308d0$0300000a@anelginanalas> <20010717173351.3967.qmail@web10005.mail.yahoo.com> <20010717143457.A2106@omnifarious.org> <3B549523.20504@uswest.net> <20010717145557.A2161@omnifarious.org> Message-ID: <20010717150647.A2264@omnifarious.org> On Tue, Jul 17, 2001 at 02:55:57PM -0500, Eric M. Hopper wrote: > On Tue, Jul 17, 2001 at 02:42:27PM -0500, Perry Hoekstra wrote: > > Eric M. Hopper wrote: > > > > > On Tue, Jul 17, 2001 at 10:33:51AM -0700, Bill Gladen wrote: > > > > > >>Interwoven. (sorry) > > >> > > > > > > For the unenlightened, what significance does the word > > > 'Interwoven' have in the discussion? > > > > > > Have fun (if at all possible), > > > > > > > The response is weaved among the content of the email that is being > > replied to. > > I realize this, but the word Interwoven is enver again mentioned > after he first mentions it, and I'm curious as to why he used it. Oops. Another off-list message made me realize my error. In my world, 'Interwoven' is the name of a company that makes release control software for large websites. The context of your discussion, combined with the single, capitalized 'Interwoven' confused me greatly. I also assume by default that comments are interwoven, so stating that they were seems strange to me. Have fun (if at all possible), -- "It does me no injury for my neighbor to say there are twenty gods or no God. It neither picks my pocket nor breaks my leg." --- Thomas Jefferson "Go to Heaven for the climate, Hell for the company." -- Mark Twain -- Eric Hopper (hopper@omnifarious.org http://www.omnifarious.org/~hopper) -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/tclug-devel/attachments/20010717/fb29e519/attachment.pgp From tanner at real-time.com Fri Jul 20 02:29:24 2001 From: tanner at real-time.com (Bob Tanner) Date: Mon Jan 17 14:29:24 2005 Subject: [TCLUG-DEVEL] JUnit vs JTest vs JProbe Message-ID: <20010720022924.K15536@real-time.com> I have been using JUnit on many of my projects. It works fine, but as time tables shrink, I started to look for something more automated. I found JTest and JProbe. Anyone have any comparisions they would like to share? Both JTest and JProbe are pricy and I don't want to go down that path if they aren't much better then JUnit. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From nobody170 at yahoo.com Fri Jul 20 07:26:30 2001 From: nobody170 at yahoo.com (Bill Gladen) Date: Mon Jan 17 14:29:24 2005 Subject: [TCLUG-DEVEL] JUnit vs JTest vs JProbe In-Reply-To: <20010720022924.K15536@real-time.com> Message-ID: <20010720122630.71783.qmail@web10007.mail.yahoo.com> Of the three, I've only used JProbe, so my input value is limitted. Jprobe has some pretty nice profiling features, and it will run in non-interactive mode spitting data into a file to be analyzed later. So if you're trying to find out why your server applications are running slow/large, it can help quite a bit. Other than that, of course, there is the standard step-through-the-running-code widget, which supposedly works well with multi-threaded apps, but I've never used that part. It has a pretty nice Iface, but if you want to do something specific, there can be a bit of an rtfm investment to find out how to do what you want. Hope that helps a little. Bill --- Bob Tanner wrote: > I have been using JUnit on many of my projects. It works fine, but as > time > tables shrink, I started to look for something more automated. > > I found JTest and JProbe. > > Anyone have any comparisions they would like to share? Both JTest and > JProbe are > pricy and I don't want to go down that path if they aren't much > better then > JUnit. > > -- > Bob Tanner | Phone : (952)943-8700 > http://www.mn-linux.org | Fax : (952)943-8500 > Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 > > _______________________________________________ > tclug-devel mailing list > tclug-devel@mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From mike at fruitioninc.com Fri Jul 20 13:02:00 2001 From: mike at fruitioninc.com (Mike Bresnahan) Date: Mon Jan 17 14:29:25 2005 Subject: [TCLUG-DEVEL] JUnit vs JTest vs JProbe References: <20010720022924.K15536@real-time.com> Message-ID: <019c01c11146$12fc6bc0$0300000a@anelginanalas> Do JProbe and JUnit have anything in common? I've used JUnit and its small java library for writing a test suite. What I know of JProbe it is a performance profiler - quite a different beast. I've never heard of JTest. Mike ----- Original Message ----- From: "Bob Tanner" To: Sent: Friday, July 20, 2001 12:29 AM Subject: [TCLUG-DEVEL] JUnit vs JTest vs JProbe > I have been using JUnit on many of my projects. It works fine, but as time > tables shrink, I started to look for something more automated. > > I found JTest and JProbe. > > Anyone have any comparisions they would like to share? Both JTest and JProbe are > pricy and I don't want to go down that path if they aren't much better then > JUnit. > > -- > Bob Tanner | Phone : (952)943-8700 > http://www.mn-linux.org | Fax : (952)943-8500 > Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 > > _______________________________________________ > tclug-devel mailing list > tclug-devel@mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel From nobody170 at yahoo.com Fri Jul 20 12:36:53 2001 From: nobody170 at yahoo.com (Bill Gladen) Date: Mon Jan 17 14:29:25 2005 Subject: [TCLUG-DEVEL] JUnit vs JTest vs JProbe In-Reply-To: <019c01c11146$12fc6bc0$0300000a@anelginanalas> Message-ID: <20010720173653.68778.qmail@web10004.mail.yahoo.com> I took a look at the JUnit site, and it looks like there are a bunch of extensions out there that you can use to do things like performance profiling (JUnitPerf) and finding design metrics (JDepend). But they did look pretty labor intensive. I also took a look at the JTest site, and it seems like it has more in common with JUnit than JProbe. The automation thing that they talk about looked like it would work well if you were already using a formalized Design by Contract markup language in your code, but I wouldn't want to try to bring it in in the middle of a project. Interesting stuff that I may eventually get around to playing with... Bill --- Mike Bresnahan wrote: > Do JProbe and JUnit have anything in common? I've used JUnit and its > small > java library for writing a test suite. What I know of JProbe it is a > performance profiler - quite a different beast. I've never heard of > JTest. > > Mike > ----- Original Message ----- > From: "Bob Tanner" > To: > Sent: Friday, July 20, 2001 12:29 AM > Subject: [TCLUG-DEVEL] JUnit vs JTest vs JProbe > > > > I have been using JUnit on many of my projects. It works fine, but > as time > > tables shrink, I started to look for something more automated. > > > > I found JTest and JProbe. > > > > Anyone have any comparisions they would like to share? Both JTest > and > JProbe are > > pricy and I don't want to go down that path if they aren't much > better > then > > JUnit. > > > > -- > > Bob Tanner | Phone : (952)943-8700 > > http://www.mn-linux.org | Fax : (952)943-8500 > > Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 > > > > _______________________________________________ > > tclug-devel mailing list > > tclug-devel@mn-linux.org > > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel > > _______________________________________________ > tclug-devel mailing list > tclug-devel@mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From jpschewe at mtu.net Fri Jul 20 19:52:05 2001 From: jpschewe at mtu.net (Jon Schewe) Date: Mon Jan 17 14:29:25 2005 Subject: [TCLUG-DEVEL] JUnit vs JTest vs JProbe In-Reply-To: <20010720022924.K15536@real-time.com> References: <20010720022924.K15536@real-time.com> Message-ID: I use all three at work. They're all for different types of testing. JUnit is required for unit tests. We write unit tests for our code, and use these as regression tests also. JProbe is used for fixing performance/memory problems. It allows us to figure out what are the slow pieces of code and where memory is causing performance problems. JTest is for the monkey on the keyboard testing. Just call every method you have and see what breaks. This is also useful because it catches cases you missed with your unit tests. Although I've found it tends to handle interfaces and factory models poorly. Bob Tanner writes: > I have been using JUnit on many of my projects. It works fine, but as time > tables shrink, I started to look for something more automated. > > I found JTest and JProbe. > > Anyone have any comparisions they would like to share? Both JTest and JProbe are > pricy and I don't want to go down that path if they aren't much better then > JUnit. > > -- > Bob Tanner | Phone : (952)943-8700 > http://www.mn-linux.org | Fax : (952)943-8500 > Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 > > _______________________________________________ > tclug-devel mailing list > tclug-devel@mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel -- Jon Schewe | http://mtu.net/~jpschewe | jpschewe@mtu.net For I am convinced that neither death nor life, neither angels nor demons, neither the present nor the future, nor any powers, neither height nor depth, nor anything else in all creation, will be able to separate us from the love of God that is in Christ Jesus our Lord. - Romans 8:38-39 From tanner at real-time.com Fri Jul 20 20:15:25 2001 From: tanner at real-time.com (Bob Tanner) Date: Mon Jan 17 14:29:25 2005 Subject: [TCLUG-DEVEL] JUnit vs JTest vs JProbe In-Reply-To: ; from jpschewe@mtu.net on Fri, Jul 20, 2001 at 07:52:05PM -0500 References: <20010720022924.K15536@real-time.com> Message-ID: <20010720201525.M28602@real-time.com> Quoting Jon Schewe (jpschewe@mtu.net): > JTest is for the monkey on the keyboard testing. Just call every method you > have and see what breaks. This is also useful because it catches cases you > missed with your unit tests. Although I've found it tends to handle > interfaces and factory models poorly. Has your return on investment on JTest been good? I was quoted $7K for it, so I want to make sure I get $7K out of it. :-) -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From jpschewe at mtu.net Sat Jul 21 01:05:18 2001 From: jpschewe at mtu.net (Jon Schewe) Date: Mon Jan 17 14:29:25 2005 Subject: [TCLUG-DEVEL] JUnit vs JTest vs JProbe In-Reply-To: <20010720201525.M28602@real-time.com> References: <20010720022924.K15536@real-time.com> <20010720201525.M28602@real-time.com> Message-ID: Bob Tanner writes: > Quoting Jon Schewe (jpschewe@mtu.net): > > JTest is for the monkey on the keyboard testing. Just call every method you > > have and see what breaks. This is also useful because it catches cases you > > missed with your unit tests. Although I've found it tends to handle > > interfaces and factory models poorly. > > Has your return on investment on JTest been good? > > I was quoted $7K for it, so I want to make sure I get $7K out of it. :-) That's a ery good point. I got a lot out of it to start with. Not so much now. I've switched a lot of stuff over to a factory architecture, where everything is interfaces and the actual implementations are package visible. The previous versions of JTest haven't been able to test this properly and I haven't had the time to check out the newest version yet. I think it's great for standard class testing though. Kind of depends on what types of projects you've got. -- Jon Schewe | http://mtu.net/~jpschewe | jpschewe@mtu.net For I am convinced that neither death nor life, neither angels nor demons, neither the present nor the future, nor any powers, neither height nor depth, nor anything else in all creation, will be able to separate us from the love of God that is in Christ Jesus our Lord. - Romans 8:38-39 From dutchman at uswest.net Wed Jul 25 09:53:31 2001 From: dutchman at uswest.net (Perry Hoekstra) Date: Mon Jan 17 14:29:26 2005 Subject: [TCLUG-DEVEL] Calling a shell script from a Java program Message-ID: <3B5EDD6B.1000702@uswest.net> Hello all, I have a question concerning calling a shell script from Java through the exec method. My problem is passing multiple values as a single variable. Example Process t_process = t_runtime.exec("webcopy 'file1.html file2.html'"); I want both files sent through to the $1 arg in my webcopy shell script. However, when webcopy is invoked, file1.html is passed through the $1 arg and file2.html is passed in the $2 arg because of the space. I have tried both single and double quotes. Is there any way to pass a space delimited string as a single arguement? -- Perry Hoekstra E-Commerce Architect Talent Software Services perry.hoekstra@talentemail.com From Troy.A.Johnson at state.mn.us Wed Jul 25 10:15:39 2001 From: Troy.A.Johnson at state.mn.us (Troy.A Johnson) Date: Mon Jan 17 14:29:26 2005 Subject: Fwd: Re: [TCLUG-DEVEL] Calling a shell script from a Javaprogram Message-ID: Can the TCLUG-DEVEL have a "Reply-To" (and maybe a "Mail-Followup-To") header on messages to the list? I have directly replied to a couple messages before I have a chance to wake up (~ noon) and look at the "To" line. Thank you for your consideration, Troy -------------- next part -------------- An embedded message was scrubbed... From: "Troy.A Johnson" Subject: Re: [TCLUG-DEVEL] Calling a shell script from a Java program Date: Wed, 25 Jul 2001 10:10:10 -0500 Size: 621 Url: http://shadowknight.real-time.com/pipermail/tclug-devel/attachments/20010725/cec92f0a/attachment.mht From kethry at winternet.com Wed Jul 25 10:19:08 2001 From: kethry at winternet.com (Liz Burke-Scovill) Date: Mon Jan 17 14:29:26 2005 Subject: [TCLUG-DEVEL] Calling a shell script from a Java program In-Reply-To: <3B5EDD6B.1000702@uswest.net> Message-ID: Silly question, I know, but does it work correctly when you run it from the prompt directly? What about: Process t_process = t_runtime.exec("webcopy \"file1.html file2.html\""); ? Liz Burke-Scovill On Wed, 25 Jul 2001, Perry Hoekstra wrote: > Hello all, > > I have a question concerning calling a shell script from Java through > the exec method. My problem is passing multiple values as a single > variable. Example > > Process t_process = t_runtime.exec("webcopy 'file1.html file2.html'"); > > I want both files sent through to the $1 arg in my webcopy shell script. > However, when webcopy is invoked, file1.html is passed through the $1 > arg and file2.html is passed in the $2 arg because of the space. I have > tried both single and double quotes. Is there any way to pass a space > delimited string as a single arguement? > > -- Imagination is intelligence having fun... e-mail: kethry@winternet.com URL: http://WWW.winternet.com/~kethry/index.html From dutchman at uswest.net Wed Jul 25 10:31:38 2001 From: dutchman at uswest.net (Perry Hoekstra) Date: Mon Jan 17 14:29:26 2005 Subject: [TCLUG-DEVEL] Calling a shell script from a Java program References: Message-ID: <3B5EE65A.6070004@uswest.net> Troy.A Johnson wrote: > Process t_process = t_runtime.exec("webcopy 'file1.html\ file2.html'"); > > might be worth a try... Tried it, there was no joy ... -- Perry Hoekstra E-Commerce Architect Talent Software Services perry.hoekstra@talentemail.com From dutchman at uswest.net Wed Jul 25 10:33:17 2001 From: dutchman at uswest.net (Perry Hoekstra) Date: Mon Jan 17 14:29:26 2005 Subject: [TCLUG-DEVEL] Calling a shell script from a Java program References: Message-ID: <3B5EE6BD.1090305@uswest.net> Liz Burke-Scovill wrote: > Silly question, I know, but does it work correctly when you run it from > the prompt directly? Yes, it runs correctly when I call it from the command line. > > What about: > > Process t_process = t_runtime.exec("webcopy \"file1.html file2.html\""); > ? Yes, I tried both single and double quotes. -- Perry Hoekstra E-Commerce Architect Talent Software Services perry.hoekstra@talentemail.com From kethry at winternet.com Wed Jul 25 10:35:26 2001 From: kethry at winternet.com (Liz Burke-Scovill) Date: Mon Jan 17 14:29:26 2005 Subject: [TCLUG-DEVEL] Calling a shell script from a Java program In-Reply-To: <3B5EE6BD.1090305@uswest.net> Message-ID: > > > > What about: > > > > Process t_process = t_runtime.exec("webcopy \"file1.html file2.html\""); > > ? > > Yes, I tried both single and double quotes. No - backslashes before the single or double quotes - quotes are special characters - if you wnat them included in the string, you need the backslash - I just tried it in my own java agent - and pass the space correctly when the \" is used rather than " alone. Liz Burke-Scovill -- Imagination is intelligence having fun... e-mail: kethry@winternet.com URL: http://WWW.winternet.com/~kethry/index.html From mike at fruitioninc.com Wed Jul 25 13:45:44 2001 From: mike at fruitioninc.com (Mike Bresnahan) Date: Mon Jan 17 14:29:26 2005 Subject: [TCLUG-DEVEL] Calling a shell script from a Java program References: <3B5EDD6B.1000702@uswest.net> Message-ID: <01f401c1153a$035abfd0$0300000a@anelginanalas> Use one of the other exec() signatures. For example, try this one: public Process exec(String[] cmdarray) throws IOException Mike Bresnahan ----- Original Message ----- From: "Perry Hoekstra" To: "tclug-devel" Sent: Wednesday, July 25, 2001 7:53 AM Subject: [TCLUG-DEVEL] Calling a shell script from a Java program > Hello all, > > I have a question concerning calling a shell script from Java through > the exec method. My problem is passing multiple values as a single > variable. Example > > Process t_process = t_runtime.exec("webcopy 'file1.html file2.html'"); > > I want both files sent through to the $1 arg in my webcopy shell script. > However, when webcopy is invoked, file1.html is passed through the $1 > arg and file2.html is passed in the $2 arg because of the space. I have > tried both single and double quotes. Is there any way to pass a space > delimited string as a single arguement? > > -- > Perry Hoekstra > E-Commerce Architect > Talent Software Services > perry.hoekstra@talentemail.com > > _______________________________________________ > tclug-devel mailing list > tclug-devel@mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel From tanner at real-time.com Wed Jul 25 12:39:44 2001 From: tanner at real-time.com (Bob Tanner) Date: Mon Jan 17 14:29:26 2005 Subject: [TCLUG-DEVEL] Calling a shell script from a Java program In-Reply-To: <3B5EDD6B.1000702@uswest.net>; from dutchman@uswest.net on Wed, Jul 25, 2001 at 09:53:31AM -0500 References: <3B5EDD6B.1000702@uswest.net> Message-ID: <20010725123944.V27548@real-time.com> Quoting Perry Hoekstra (dutchman@uswest.net): > Hello all, > > I have a question concerning calling a shell script from Java through > the exec method. My problem is passing multiple values as a single > variable. Example > > Process t_process = t_runtime.exec("webcopy 'file1.html file2.html'"); > > I want both files sent through to the $1 arg in my webcopy shell script. > However, when webcopy is invoked, file1.html is passed through the $1 > arg and file2.html is passed in the $2 arg because of the space. I have > tried both single and double quotes. Is there any way to pass a space > delimited string as a single arguement? > Process t_process = t_runtime.exec("webcopy 'file1.html\ file2.html'"); Escaping the space? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From nobody170 at yahoo.com Wed Jul 25 12:45:13 2001 From: nobody170 at yahoo.com (Bill Gladen) Date: Mon Jan 17 14:29:26 2005 Subject: [TCLUG-DEVEL] Calling a shell script from a Java program In-Reply-To: <01f401c1153a$035abfd0$0300000a@anelginanalas> Message-ID: <20010725174513.66955.qmail@web10006.mail.yahoo.com> That's what I would suggest. You may have to doctor it a bit as well; for instance: rt.exec( new String[]{ "webcopy", "\"f1.html f2.html\"" } ); (notice the escaped double quotes surrounding the second string). Note that the docs say that exec( String ) uses a StringTokenizer to break things up into tokens, and recall that StringTokenizer just uses a non-context-sensitive search for token delimiters (whitespace). That's why the other one wasn't working. Bill --- Mike Bresnahan wrote: > Use one of the other exec() signatures. For example, try this one: > > public Process exec(String[] cmdarray) throws IOException > > Mike Bresnahan > > ----- Original Message ----- > From: "Perry Hoekstra" > To: "tclug-devel" > Sent: Wednesday, July 25, 2001 7:53 AM > Subject: [TCLUG-DEVEL] Calling a shell script from a Java program > > > > Hello all, > > > > I have a question concerning calling a shell script from Java > through > > the exec method. My problem is passing multiple values as a single > > > variable. Example > > > > Process t_process = t_runtime.exec("webcopy 'file1.html > file2.html'"); > > > > I want both files sent through to the $1 arg in my webcopy shell > script. > > However, when webcopy is invoked, file1.html is passed through > the $1 > > arg and file2.html is passed in the $2 arg because of the space. I > have > > tried both single and double quotes. Is there any way to pass a > space > > delimited string as a single arguement? > > > > -- > > Perry Hoekstra > > E-Commerce Architect > > Talent Software Services > > perry.hoekstra@talentemail.com > > > > _______________________________________________ > > tclug-devel mailing list > > tclug-devel@mn-linux.org > > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel > > _______________________________________________ > tclug-devel mailing list > tclug-devel@mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-devel __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From dutchman at uswest.net Wed Jul 25 13:22:46 2001 From: dutchman at uswest.net (Perry Hoekstra) Date: Mon Jan 17 14:29:26 2005 Subject: [TCLUG-DEVEL] Calling a shell script from a Java program References: <3B5EDD6B.1000702@uswest.net> <20010725123944.V27548@real-time.com> Message-ID: <3B5F0E76.3030000@uswest.net> Bob Tanner wrote: > Quoting Perry Hoekstra (dutchman@uswest.net): > >>Hello all, >> >>I have a question concerning calling a shell script from Java through >>the exec method. My problem is passing multiple values as a single >>variable. Example >> >>Process t_process = t_runtime.exec("webcopy 'file1.html file2.html'"); >> >>I want both files sent through to the $1 arg in my webcopy shell script. >> However, when webcopy is invoked, file1.html is passed through the $1 >>arg and file2.html is passed in the $2 arg because of the space. I have >>tried both single and double quotes. Is there any way to pass a space >>delimited string as a single arguement? >> >> > > Process t_process = t_runtime.exec("webcopy 'file1.html\ file2.html'"); > > Escaping the space? Troy Johnson suggested that and I tried it but there was no joy ... -- Perry Hoekstra E-Commerce Architect Talent Software Services perry.hoekstra@talentemail.com From dutchman at uswest.net Wed Jul 25 16:11:42 2001 From: dutchman at uswest.net (Perry Hoekstra) Date: Mon Jan 17 14:29:26 2005 Subject: [TCLUG-DEVEL] Calling a shell script from a Java program References: <20010725174513.66955.qmail@web10006.mail.yahoo.com> Message-ID: <3B5F360E.7020809@uswest.net> Bill Gladen wrote: > That's what I would suggest. You may have to doctor it a bit as well; > for instance: > > rt.exec( new String[]{ "webcopy", "\"f1.html f2.html\"" } ); > > (notice the escaped double quotes surrounding the second string). > > Note that the docs say that exec( String ) uses a StringTokenizer to > break things up into tokens, and recall that StringTokenizer just uses > a non-context-sensitive search for token delimiters (whitespace). > That's why the other one wasn't working. Thank you for the insight, that fixed my problem. -- Perry Hoekstra E-Commerce Architect Talent Software Services perry.hoekstra@talentemail.com