comp.lang.java.programmer http://groups-beta.google.com/group/comp.lang.java.programmer [EMAIL PROTECTED]
Today's topics: * Why would file reading stop at 1124 bytes with this code? - 11 messages, 7 authors http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/f79ea47a0b0aea21 * Releasing Precompiled JSP for Tomcat 4.1.x - 2 messages, 2 authors http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/2c21d87040a82ddc * JMF send live stream from local PC to global server - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/215fa5e98c39b755 * Building an Exception Layer - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/a8359d1a0e5422fb * NullPointerException with FileInputStream - 2 messages, 2 authors http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/31f437f0b81b32cd * regex replace \\ by \ - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/9f662bcf0fda45f7 * Apache Axis and JDK1.5 - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/274cfa6bf37ead9b * socket & JVM - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/62667ce992bbc83e * Java Sound API adjust playback speed? - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/fd4cf8ac5f8c6b76 * Performance of null tests? - 2 messages, 2 authors http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/e1febd5672a2f269 * java.net.SocketException: Insufficient buffer space - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/7c9c56b240ed60b1 * newbie compile question - 2 messages, 2 authors http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/8de296cba22d3831 * newbie exceptions question - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/80a2d1cab77381a * Calendar.roll on december,31 !!!! - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/ea6aea82ed17ba7a * Setting up Java 2 SDK - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/f716f93502b214ca * JMF usage question - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/aad921bc1cea5088 ========================================================================== TOPIC: Why would file reading stop at 1124 bytes with this code? http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/f79ea47a0b0aea21 ========================================================================== == 1 of 11 == Date: Thurs, Nov 4 2004 11:59 am From: "Mickey Segal" <[EMAIL PROTECTED]> The code below runs in a servlet; it reads the file and then deletes it. Usually this works fine, but with larger files about 10% of the time the reportString gets truncated at 1124 bytes. My guess is that File.delete is being called before adding to reportString is finished, but I thought File.delete would only be called after file reading finishes. Can someone help by pointing out what I am doing wrong here? Suggestions about how to fix the code would be particularly welcome. The code: final synchronized String read_delete(String fullPathAndFileString) { FileInputStream fis = null; BufferedInputStream bis = null; DataInputStream dataIS = null; String reportString = ""; try { File fNow = new File(fullPathAndFileString); fis = new FileInputStream(fNow); bis = new BufferedInputStream(fis); dataIS = new DataInputStream(bis); int bytesAvailable; while ((bytesAvailable = bis.available()) > 0) { byte[] b = new byte[bytesAvailable]; dataIS.readFully(b); reportString += new String(b); } fNow.delete(); } catch (EOFException ignored) {} catch (FileNotFoundException ignored) {} catch (IOException ignored) {} finally { try { if (dataIS != null) dataIS.close(); if (bis != null) bis.close(); if (fis != null) fis.close(); } catch (IOException ignored) {} } return(reportString); } == 2 of 11 == Date: Thurs, Nov 4 2004 12:24 pm From: Carl Howells <[EMAIL PROTECTED]> Mickey Segal wrote: > The code below runs in a servlet; it reads the file and then deletes it. > Usually this works fine, but with larger files about 10% of the time the > reportString gets truncated at 1124 bytes. My guess is that File.delete is > being called before adding to reportString is finished, but I thought > File.delete would only be called after file reading finishes. > > Can someone help by pointing out what I am doing wrong here? Suggestions > about how to fix the code would be particularly welcome. > > The code: > > final synchronized String read_delete(String fullPathAndFileString) > { > FileInputStream fis = null; > BufferedInputStream bis = null; > DataInputStream dataIS = null; > String reportString = ""; Ack. You only ever use dataIS, outside of initialization and closing (and it's not necessary to use the others there, either)... Why do you have variables for the other two? Just chain the constructors together. It makes it clearer that they're not being used except as intermediate values. Additionally, you don't need to use a DataInputStream for this at all. BufferedInputStream's read() method is clearly sufficient. > try > { > File fNow = new File(fullPathAndFileString); > fis = new FileInputStream(fNow); > bis = new BufferedInputStream(fis); > dataIS = new DataInputStream(bis); > int bytesAvailable; > while ((bytesAvailable = bis.available()) > 0) Bad! Don't use available for *anything*... It's fundamentally broken. It's certainly the cause of your problem. Just use the return value from read(). If it's negative, you've reached the end of the file. > { > byte[] b = new byte[bytesAvailable]; > dataIS.readFully(b); > reportString += new String(b); Bad #1: You should use an explicit conversion from bytes to String, rather than the system default. Bad #2: You're using += with strings, in a loop. Unless you need to use each string generated this way (which you clearly don't, in this case... You only need the final result), this is awfully inefficient. Use a StringBuffer or StringBuilder, depending on your target java version (StringBuilder in 1.5). > } > fNow.delete(); > } > catch (EOFException ignored) {} > catch (FileNotFoundException ignored) {} > catch (IOException ignored) {} > finally > { > try > { > if (dataIS != null) dataIS.close(); > if (bis != null) bis.close(); > if (fis != null) fis.close(); Calling close on any of the decorator InputStreams also closes the stream they decorate. Closing only the outermost one is fine. > } > catch (IOException ignored) {} > } > return(reportString); > } == 3 of 11 == Date: Thurs, Nov 4 2004 12:39 pm From: Steve Horsley <[EMAIL PROTECTED]> Mickey Segal wrote: > The code below runs in a servlet; it reads the file and then deletes it. > Usually this works fine, but with larger files about 10% of the time the > reportString gets truncated at 1124 bytes. My guess is that File.delete is > being called before adding to reportString is finished, but I thought > File.delete would only be called after file reading finishes. > > Can someone help by pointing out what I am doing wrong here? Suggestions > about how to fix the code would be particularly welcome. > > The code: <snip> I suspect the problem is caused by your using InputStream.available(). This merely returns the number of bytes that can be guaranteed to be supplied without the possibility of blocking. If there is any doubt as to whether a read would block or not then available() MUST return 0. This doesn't mean you've reached the end of the file, just that there might be a pause before you can read any more. I think you should not use available() at all - just read until you get an EOF. Steve. == 4 of 11 == Date: Thurs, Nov 4 2004 12:45 pm From: Carl <[EMAIL PROTECTED]> Response clipped, question inline... > Mickey Segal wrote: > > >> { >> byte[] b = new byte[bytesAvailable]; >> dataIS.readFully(b); >> reportString += new String(b); > > > Bad #1: You should use an explicit conversion from bytes to String, > rather than the system default. > Would you mind elaborating on this. I Assume you are referring to the "new String(b)" statement. Why is this wrong, and what exactly is the system default? Thanks, Carl. == 5 of 11 == Date: Thurs, Nov 4 2004 12:48 pm From: "Mickey Segal" <[EMAIL PROTECTED]> "Carl Howells" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Additionally, you don't need to use a DataInputStream for this at all. > BufferedInputStream's read() method is clearly sufficient. > Bad! Don't use available for *anything*... It's fundamentally broken. > It's certainly the cause of your problem. Just use the return value from > read(). If it's negative, you've reached the end of the file. I used DataInputStream to get DataInputStream.readFully() but I will try using the approach you suggested using read() instead. > Bad #1: You should use an explicit conversion from bytes to String, > rather than the system default. > > Bad #2: You're using += with strings, in a loop. Unless you need to use > each string generated this way (which you clearly don't, in this case... > You only need the final result), this is awfully inefficient. Use a > StringBuffer or StringBuilder, depending on your target java version > (StringBuilder in 1.5). The vast majority of files read are tiny so I was trying to avoid StringBuffer code, but I suppose it makes more sense to optimize for the rare longer files. Thanks. They should put warning labels on methods that are fundamentally broken. Does someone keep a list of such methods? == 6 of 11 == Date: Thurs, Nov 4 2004 12:59 pm From: Tor Iver Wilhelmsen <[EMAIL PROTECTED]> "Mickey Segal" <[EMAIL PROTECTED]> writes: > The vast majority of files read are tiny so I was trying to avoid > StringBuffer code, but I suppose it makes more sense to optimize for the > rare longer files. Using string concatenation is the same as implicitly using StringBuffer anyway. Except you create a new one and throw it away for each iteration. == 7 of 11 == Date: Thurs, Nov 4 2004 1:38 pm From: Chris Smith <[EMAIL PROTECTED]> Carl wrote: > > Bad #1: You should use an explicit conversion from bytes to String, > > rather than the system default. > > > > Would you mind elaborating on this. I Assume you are referring to the > "new String(b)" statement. Why is this wrong, and what exactly is the > system default? What Carl is referring to is the character encoding. A character encoding is the conversion between characters and bytes. For example, ASCII maps a certain limited set of characters to the numbers 0-127. Various ISO8859 standards extend ASCII with different (and incompatible) characters mapped to bytes 128-255, so that the whole ASCIOI character set plus a few extra characters can be included. There are also multibyte encodings, such as UTF-16BE and UTF-16LE, which use two bytes per character and can express the entire Unicode character set. Finally, there are variable-length encodings such as UTF-8, in which some characters (such as ASCII characters) take up only one byte, but others can take two or more. Each operating system (and sometimes depending on the localization of the OS) chooses a default character encoding. That's okay for temporary storage that will never extend beyond this system, such as for simple application preferences. For anything that will be stored in a user- exposed file, transferred over a network, or ANYTHING else where there's a remote possibility that a file will be moved to a different machine, you should pick a very specific encoding, such as ASCII or UTF-8. All conversions between bytes and characters can take a character encoding name as a parameter. Look for that overload in the API docs. In particular, the constructor for String and String.getBytes both have these overloads. InputStreamReader and OutputStreamWriter both have constructors that take an encoding parameter as well. -- www.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation == 8 of 11 == Date: Thurs, Nov 4 2004 1:39 pm From: "John C. Bollinger" <[EMAIL PROTECTED]> Carl wrote: > Response clipped, question inline... > >> Mickey Segal wrote: >> >> >>> { >>> byte[] b = new byte[bytesAvailable]; >>> dataIS.readFully(b); >>> reportString += new String(b); >> >> >> >> Bad #1: You should use an explicit conversion from bytes to String, >> rather than the system default. >> > > Would you mind elaborating on this. I Assume you are referring to the > "new String(b)" statement. Why is this wrong, and what exactly is the > system default? In answer to your first question, it's wrong because there is no universal answer to your second question. When you want to convert between bytes and characters you should _always_ specify the charset to use. Not only does it ensure that your program does not break (in this regard) when you move it between machines or upgrade your machine's JRE, it also documents your assumptions about the data your program is intended to work with. John Bollinger [EMAIL PROTECTED] == 9 of 11 == Date: Thurs, Nov 4 2004 3:38 pm From: "Mickey Segal" <[EMAIL PROTECTED]> "Carl" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Would you mind elaborating on this. I Assume you are referring to the "new > String(b)" statement. Why is this wrong, and what exactly is the system > default? In re-writing the program I see another problem with the "new String(b)" statement. On the final loop in which the byte array does not get filled up completely there are old characters in the unused part at the end of the byte array, so one needs to create a smaller String to include only the new part of the byte array. == 10 of 11 == Date: Thurs, Nov 4 2004 3:40 pm From: "Mickey Segal" <[EMAIL PROTECTED]> "Chris Smith" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > All conversions between bytes and characters can take a character > encoding name as a parameter. Look for that overload in the API docs. > In particular, the constructor for String and String.getBytes both have > these overloads. InputStreamReader and OutputStreamWriter both have > constructors that take an encoding parameter as well. How far back in Java does this feature go? We are keeping all our client-side programming at Java 1.1 for now. == 11 of 11 == Date: Thurs, Nov 4 2004 3:42 pm From: "Mickey Segal" <[EMAIL PROTECTED]> "Mickey Segal" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > How far back in Java does this feature go? We are keeping all our > client-side programming at Java 1.1 for now. Oops. I just found this in Java 1.1. ========================================================================== TOPIC: Releasing Precompiled JSP for Tomcat 4.1.x http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/2c21d87040a82ddc ========================================================================== == 1 of 2 == Date: Thurs, Nov 4 2004 12:32 pm From: [EMAIL PROTECTED] (Steve) Is it possible to release out only precompiled classes of the JSP pages and not the actual JSP and source code within it? (JSP contains java source code which I would not like to be visible.) == 2 of 2 == Date: Thurs, Nov 4 2004 1:48 pm From: "John C. Bollinger" <[EMAIL PROTECTED]> Steve wrote: > Is it possible to release out only precompiled classes of the JSP > pages and not the actual JSP and source code within it? (JSP contains > java source code which I would not like to be visible.) Yes it is. There are standalone JSP compilers available, for instance jspc which comes with Tomcat. On the other hand, _good_ JSP code doesn't contain much, if any, Java source code. You might save yourself some trouble by moving your scriptlet code into beans and/or custom tags. If you use JSP 2 then that can be facilitated by replacing some other scriptlet code with JSP expression language expressions. Also, you should keep in mind that compiling your JSPs to bytecode is only the most rudimentary form of obfuscation. Most people who write plain Java classes wouldn't consider it to be obfuscation at all. It is pretty straightforward to decompile a Java class file. In your case the curious third party decompiling your class would end up with source for a servlet representation of it, not the JSP source, but that doesn't get much in the way of seeing at least the gist of your Java. John Bollinger [EMAIL PROTECTED] ========================================================================== TOPIC: JMF send live stream from local PC to global server http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/215fa5e98c39b755 ========================================================================== == 1 of 1 == Date: Thurs, Nov 4 2004 12:47 pm From: [EMAIL PROTECTED] (derek) hello, I'd like to capture audio/video from my local PC, and transmit it to a global server which has static unique IP, which will send my content to some audiences. Since the local PC has no unique IP, the server can't call RTPManager.addTarget(...) to receive live stream. Someone recommends me transfer the stream using servlet. But I have no idea since I can not get any output stream from JMF. Is it possible using JMF RTP, and how? Thanks a lot, Derek ========================================================================== TOPIC: Building an Exception Layer http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/a8359d1a0e5422fb ========================================================================== == 1 of 1 == Date: Thurs, Nov 4 2004 1:04 pm From: Chris Smith <[EMAIL PROTECTED]> Rizwan wrote: > then it would be MITBaseException (MIT being the software product name which > we are creating). But then I have to include MIT with other exception name > as well for example MITPermissionException, etc. That's the basic idea. I'd suggest MITException as opposed to MITBaseException. The "base" is still an implementation word, and just grates a bit when used from a client. The client shouldn't care if it's a "base" for some other exception; only if it's the exception the client is interested in. As for "MITPermissionException", that's probably a good idea just because "permission" is so vague. For a less vague word, it might not be necessary; for example, FileNotFoundException is not called IOFileNotFoundException, because the name is descriptive enough. -- www.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation ========================================================================== TOPIC: NullPointerException with FileInputStream http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/31f437f0b81b32cd ========================================================================== == 1 of 2 == Date: Thurs, Nov 4 2004 1:06 pm From: Mark F <[EMAIL PROTECTED]> Mark F wrote: > For some reason I'm getting an NPE at this line: > > fis = new FileInputStream(HitCountFilter.HITS_FILENAME); > > HITS_FILENAME is a static variable that is set to "C:\\hits.ser" > > Counter is a simple object with a funcion that is self-explanatory. It > implements serializable. > > Here is the code: > > > public void init(FilterConfig fc) throws ServletException { > this.filterConfig = fc; > FileInputStream fis = null; > ObjectInputStream ois = null; > > try { > fis = new FileInputStream(HitCountFilter.HITS_FILENAME); > } > catch (FileNotFoundException ex) { > ... > } > catch (NullPointerException npe) { > ... > } > try { > if (fis != null) { > ois = new ObjectInputStream(fis); > count = (Counter) ois.readObject(); > } > else { > count = new Counter(0); > } > } > catch (ClassNotFoundException ex2) { > ... > } > catch (IOException ex2) { > ... > } > finally { > try { > ois.close(); > fis.close(); > } > catch (IOException ex3) { > ... > } > } > } It is my understanding that you don't need to ( test for ) and create the actual file but that the act of opening a FileOutputStream will itself create the file. This however has not been by experience in practice?? Thanks, -Mark == 2 of 2 == Date: Thurs, Nov 4 2004 1:41 pm From: "Mike Schilling" <[EMAIL PROTECTED]> "Mark F" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > It is my understanding that you don't need to ( test for ) and create the > actual file but that the act of opening a FileOutputStream will itself > create the file. Yes, this is correct. Creating the file first is somewhat useless, since the output from the FileOutputStream would immediately overwrite it. >This however has not been by experience in practice?? The file won't be created when it's not possible: readonly filesystem, readonly directory, insufficient permissions, etc. ========================================================================== TOPIC: regex replace \\ by \ http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/9f662bcf0fda45f7 ========================================================================== == 1 of 1 == Date: Thurs, Nov 4 2004 1:23 pm From: Alan Moore <[EMAIL PROTECTED]> On Thu, 04 Nov 2004 09:34:25 -0500, "John C. Bollinger" <[EMAIL PROTECTED]> wrote: > > thanks for your fast replies. But unfortunately none of your solutions > > solves my problem. I have written a second example. > > We understand your problem. You are mistaken about not having a > solution. Your test is buggy. *I* didn't understand the problem, because he misstated it. He doesn't want to replace two backslashes with one, he wants to replace whitespace escpes with the characters they represent. For that problem, there's no particular advantage to using regular expressions. The appendXXX methods from the Matcher class can be useful (as I demonstrate below), but not compellingly so. Pattern p = Pattern.compile("\\\\."); Matcher m = p.matcher(str); StringBuffer sb = new StringBuffer(); while (m.find()) { m.appendReplacement(sb, ""); char c = m.group().charAt(1); switch (c) { case 'n': sb.append('\n'); break; case 't': sb.append('\t'); break; // handle other escapes default: sb.append(m.group()); // or maybe drop the backslash } } m.appendTail(sb); So you /can/ use the regex package for this problem, but just iterating through the string with charAt() takes the same amount of effort, and is easier to read and maintain. ========================================================================== TOPIC: Apache Axis and JDK1.5 http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/274cfa6bf37ead9b ========================================================================== == 1 of 1 == Date: Thurs, Nov 4 2004 1:21 pm From: "Mike Schilling" <[EMAIL PROTECTED]> "Jacob" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >I have downloaded axis1.2rc and try to compile with the 1.5 > compiler and it fails because Axis (still) uses "enum" as a > package name. ("enum" is a reserved word in Java 1.5; Its > introduction has been known for a very long time). > Try what I suggested last time you brought this up: use the "-source 1.4" flag on javac. ========================================================================== TOPIC: socket & JVM http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/62667ce992bbc83e ========================================================================== == 1 of 1 == Date: Thurs, Nov 4 2004 1:47 pm From: Chris Smith <[EMAIL PROTECTED]> Anceschi Mauro wrote: > the problem is: every request launch another JVM for handle the print > and create a pdf of the the spool data: for some reason if i create > a batch that launch 5 spool file one after the other, the print > server launch 5 thread, but some thread terminate not correctly. First of all, you are not launching another JVM when you create a new thread. Unfortunately, a bug in the Linux 'ps' utility made it look that way for a long time. Recently, a new release of the Linux kernel fixed that bug (the fix is referred to as NPTL), so recent versions of the kernel are less confusing. > In particular the exit code are 1-0-1-0-0 so the first fail, the > second is executed and so on..... Threads don't have exit codes. You're seeing some artifact of the threading library implementation on your old version of the Linux kernel. This is an artifact of the same bug. Unless you're seeing actual symptoms, there is very likely no problem at all. If this bothers you, then update your Linux kernel and basic utilities to eliminate the broken reporting tools. By the way, can you please configure your newsreader to break lines. It took a lot of effort to reply to you in a way that everyone can read. I probably won't reply again if I have to keep doing so. -- www.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation ========================================================================== TOPIC: Java Sound API adjust playback speed? http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/fd4cf8ac5f8c6b76 ========================================================================== == 1 of 1 == Date: Thurs, Nov 4 2004 2:13 pm From: "Boudewijn Dijkstra" <[EMAIL PROTECTED]> "Mike" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] > "Boudewijn Dijkstra" <[EMAIL PROTECTED]> wrote in message > news:<[EMAIL PROTECTED]>... >> "Mike" <[EMAIL PROTECTED]> schreef in bericht >> news:[EMAIL PROTECTED] >> > In Windows media/other audio apps you can adjust the playback speed >> > of an audio file while MAINTAINING pitch. >> > >> > Was wondering how to do this with java sound. >> > >> > found: >> > SampleRateControl >> > >> > by searching, but as far as I can understand, this will only alter >> > the PITCH and SPEED at the same time. Just want to control speed, >> > maintain PITCH. >> >> I'm afraid you'll have to this manually by calculating a band shift >> in the frequency domain after increasing the speed+pitch. > > Do you have any pointers/links for guidelines on this process? > Haven't been able to find anything searching so far on it. If not, > thanks for the help anyway. 1. resample to the desired speed (including the pitch-altering side-effects) 2. FFT (enter the frequency domain) 3. resample to the correct shift (removing the side-effects) 4. reverse FFT (leave the frequency domain) Please be aware that I haven't tried this myself nor do I know whether 'the professionals' do it this way. But it will definately work, if executed correctly. Although I cannot guarantee good sound quality for other speed changes than those by a factor of a whole power of two. In short, I'd like to see what you make of it. ========================================================================== TOPIC: Performance of null tests? http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/e1febd5672a2f269 ========================================================================== == 1 of 2 == Date: Thurs, Nov 4 2004 2:21 pm From: "Boudewijn Dijkstra" <[EMAIL PROTECTED]> "VisionSet" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] > > "Adam" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> I've just been having a discussion with a colleague and would be >> interested to hear people's opinions on which of the below code >> snippets would have the highest performance overhead. >> >> Assume that <do good stuff> would throw a NullPointerException if >> badger was null. >> >> (A) >> >> if(badger == null) { >> <do bad stuff> >> } else { >> <do good stuff> >> } >> >> (B) >> >> try { >> <do good stuff> >> } catch (NullPointerException npe) { >> <do bad stuff> >> } >> >> > > If badger is truly exceptionally null then (B) will be best because > there is no conditional to test and there will rarely be any overhead > of throwing the exception. > On the other hand if badger is often null then (A) would be better > since testing for null is very low overhead. Whilst throwing an > exception is high overhead. In other words: it depends. It depends on the chance of an exception occuring and the performance difference between the approaches. == 2 of 2 == Date: Thurs, Nov 4 2004 3:16 pm From: Eric Sosman <[EMAIL PROTECTED]> Boudewijn Dijkstra wrote: > "VisionSet" <[EMAIL PROTECTED]> schreef in bericht > news:[EMAIL PROTECTED] > >>"Adam" <[EMAIL PROTECTED]> wrote in message >>news:[EMAIL PROTECTED] >> >>>I've just been having a discussion with a colleague and would be >>>interested to hear people's opinions on which of the below code >>>snippets would have the highest performance overhead. >>> >>>Assume that <do good stuff> would throw a NullPointerException if >>>badger was null. >>> >>>(A) >>> >>>if(badger == null) { >>> <do bad stuff> >>>} else { >>> <do good stuff> >>>} >>> >>>(B) >>> >>>try { >>> <do good stuff> >>>} catch (NullPointerException npe) { >>> <do bad stuff> >>>} >>> >>> >> >>If badger is truly exceptionally null then (B) will be best because >>there is no conditional to test and there will rarely be any overhead >>of throwing the exception. >>On the other hand if badger is often null then (A) would be better >>since testing for null is very low overhead. Whilst throwing an >>exception is high overhead. > > > In other words: it depends. It depends on the chance of an exception occuring > and the performance difference between the approaches. The `if' will probably turn into just a few instructions once the JIT gets through with it -- ten instructions seems high, but let's just suppose it's ten. We're working on the back of the envelope here, okay? Creating and catching the exception will take a variable amount of work depending on how deep the stack happens to be, but let's be optimistic and suppose it takes only ten thousand instructions, including the eventual cost of garbage collecting the NullPointerException object after it's been discarded. Under these suppositions, one exception carries the time penalty of a thousand `if' tests. Using an exception to avoid the `if' would be a win if the reference is null less than one thousandth of the time, non-null more than 99.9% of the time. How much of a gain can you get? Let's suppose the reference is null just one ten-thousandth of the time, one tenth of the break-even point. If the code executes a million times, you'll throw one hundred exceptions at a (supposed) cost of one million instructions. Meanwhile, you've avoided (supposedly) ten million instructions for the `if' tests you didn't make. The gain is nine million instructions, which sounds pretty good. But how good is it, really? Well, processors vary and caches vary and memory speeds vary and blah blah blah, but let's be pessimistic and assume you can execute instructions at a rate of only 1GHz. You have saved nine milliseconds. Nine whole milliseconds. nine thousandths of one second You have klutzed up your code, and even under the most optimistic assumptions imaginable a million executions of the "optimized" version have saved you nine thousandths of one second That's roughly the amount of time between successive wave crests of the note on the bottom line of the bass clef, two octaves below concert A. nine thousandths of one second It's about two-thirds the time of one CRT refresh. nine thousandths of one second It's enough time for a race car going 200 miles/hour to travel thirty-two inches. nine thousandths of one second Let me ask you this: What are you going to do with all that extra time? Won't it hang heavy on your hands? -- [EMAIL PROTECTED] ========================================================================== TOPIC: java.net.SocketException: Insufficient buffer space http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/7c9c56b240ed60b1 ========================================================================== == 1 of 1 == Date: Thurs, Nov 4 2004 2:56 pm From: "Jeff" <[EMAIL PROTECTED]> "John C. Bollinger" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >I wrote: >> wasting memory. Unless you can determine the message size before >> allocating the buffer, you have an unavoidable space / speed tradeoff >> going on here. > > Which is true as far as it goes, but upon further reflection I realize > that if the typical message is considerably smaller than the largest > possible message, and if there are a lot of messages, then the time to > allocate (and later GC) a large amount of unused buffer space many times > may trump the time it takes to copy bytes around in a scheme that uses a > smaller buffer by default and expands it as necessary for large messages. > Such an adaptation scheme could be incorporated into my example code, but > I'll spare you the details. > > This all comes back around to the point that you need to _test_ to > determine where your performance problems are, and you need to _test_ to > determine whether any hand optimization you come up with actually improves > performance. > > > John Bollinger > [EMAIL PROTECTED] We deal with the variable message size by sending/reading a fixed length header which contains the message size. Then we allocate a buffer of that message size and read the rest of the message. We did get rid of BufferedInputStream based on this newsgroup's input. The application runs much faster. Using one of our basic load tests, the application runs 3x faster. Clearly the BufferedInputStream was a bottleneck. It also seems to have eliminated the bug that started this thread, but we need more testing to verify that. John's read loop was much better than my old one so I swapped his in, with a few adaptions. Here it is. // assume we've read the message header and determined the msgLength msgBuffer = new byte[msgLength]; bytesRead = 0; for ( int numRead = inputStream.read( msgBuffer , bytesRead , msgBuffer.length - bytesRead ); numRead > 0; numRead = inputStream.read( msgBuffer , bytesRead , msgBuffer.length - bytesRead ) ) { if ( numRead == -1 ) { // I need to call a clean up method if the probe sends -1 finalize( "bytes Read = -1" ); } else bytesRead += numRead; } On profiling, we use both OptimizeIt and JRockit's JRA to profile. However, it's hard to identify where code waits for input. Thanks for the help! ========================================================================== TOPIC: newbie compile question http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/8de296cba22d3831 ========================================================================== == 1 of 2 == Date: Thurs, Nov 4 2004 2:57 pm From: [EMAIL PROTECTED] (Fahd Shariff) You can use something ugly like: javac */*/.../*.java Or use command substitution from the root source directory: javac `find . -name *.java` But my favourite is ant. If you dont know it, learn it. Its a great skill to have. -- Fahd Shariff http://www.fahdshariff.cjb.net "Let the code do the talking..." == 2 of 2 == Date: Thurs, Nov 4 2004 3:38 pm From: Andrew Thompson <[EMAIL PROTECTED]> On Thu, 04 Nov 2004 11:01:07 -0500, Nandan wrote: > Sub: newbie ... question ..best dealt with on a group described here.. <http://www.physci.org/codes/javafaq.jsp#cljh> -- Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.LensEscapes.com/ Images that escape the mundane ========================================================================== TOPIC: newbie exceptions question http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/80a2d1cab77381a ========================================================================== == 1 of 1 == Date: Thurs, Nov 4 2004 3:00 pm From: [EMAIL PROTECTED] (Fahd Shariff) The class bm.Tests.TestDiv can't be found. Make sure its in the jar WizTest_fat.jar since that is the only place that is being searched... -- Fahd Shariff http://www.fahdshariff.cjb.net "Let the code do the talking..." Nandan <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > java -classpath WizTest_fat.jar bm.Tests.TestDiv tests/divtest4.xml > Exception in thread "main" java.lang.NoClassDefFoundError: bm/Tests/TestDiv > > > > It might be worthwhile to catch this exception in the program and > > offer a more informative error message. > > am I correct in thinking the following? > > That will not work. There is no way to catch that exception, as I understand > it. It isn't even a 'real' exception, as none of our code has been executed > at that point. It is really an error message from the java interpreter to > say it couldn't find the file. I may be wrong on this though, I will check. ========================================================================== TOPIC: Calendar.roll on december,31 !!!! http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/ea6aea82ed17ba7a ========================================================================== == 1 of 1 == Date: Thurs, Nov 4 2004 3:33 pm From: [EMAIL PROTECTED] (Alex Kay) [EMAIL PROTECTED] (Gianni) wrote in message news:<[EMAIL PROTECTED]>... > My application has this terrible bug and now is time to fix! > It works 364 days in the year but not on dec,31 > > I have to add one day to the "today". > > In fact on 2004-dec-31 I have 2004-jan-1 > > I use : > Calendar calendar = Calendar.getInstance(Locale.GERMANY); > calendar.roll(6, 1); > > but obviously does not work on dec,31... any idea how to fix it??? Hi, 1. It isn't good practice to say "6" say Calendar.DAY_OF_YEAR ;-) 2. the second parameter is a boolean not an integer 3. the following may not be perfect but it works. Calendar cal = Calendar.getInstance (Locale.GERMANY); // Set to 31-Dec-2004 cal.set (2004, 11, 31, 0, 0, 0); /* * Problem. cal.roll (Calendar.DAY_OF_YEAR, true); * fails to handle 31-Dec as desired * the year doesn't change. * * A solution. Roll time forward by 24 hours in * terms of milliseconds. */ cal.setTimeInMillis( cal.getTimeInMillis() + (24*60*60*1000)); System.out.println (new Date(cal.getTimeInMillis())); 4. I just have my own methods like this. They works across day light saving too (which is often where things break). static void nextDay (Calendar cal) { cal.setTimeInMillis( cal.getTimeInMillis() + (24*60*60*1000)); } // And or static void nextDay (Date d) { d.setTime( d.getTime() + (24*60*60*1000)); } Hope that helps Alex Kay ========================================================================== TOPIC: Setting up Java 2 SDK http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/f716f93502b214ca ========================================================================== == 1 of 1 == Date: Thurs, Nov 4 2004 3:36 pm From: Andrew Thompson <[EMAIL PROTECTED]> On 4 Nov 2004 10:33:55 -0800, Mikey2jags wrote: > Hi there, ECHO, Echo, echo.. Please refrain from multi-posting. <http://www.physci.org/codes/javafaq.jsp#xpost> You have already received responses on the other thread. -- Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.LensEscapes.com/ Images that escape the mundane ========================================================================== TOPIC: JMF usage question http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/aad921bc1cea5088 ========================================================================== == 1 of 1 == Date: Thurs, Nov 4 2004 3:42 pm From: Andrew Thompson <[EMAIL PROTECTED]> On Thu, 04 Nov 2004 17:25:22 GMT, Ted Holden wrote: > On Thu, 04 Nov 2004 02:40:06 GMT, Andrew Thompson > <[EMAIL PROTECTED]> wrote: > >>On Wed, 03 Nov 2004 21:12:40 GMT, Ted Holden wrote: >> >>> I've ended up with a situation which positively requires Java, >> >>If that requirement is 'x-plat', you may get some nasty >>surprises when using JMF. Some of it is not (x-plat). > > > What exactly is x-plat? Cross platform, or.. > Basically, all I need is somethinng which works and is reasonably > portable 'portable' across platforms. It depends on the media types (which you have thus far not specified). -- Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.LensEscapes.com/ Images that escape the mundane ======================================================================= You received this message because you are subscribed to the Google Groups "comp.lang.java.programmer". comp.lang.java.programmer [EMAIL PROTECTED] Change your subscription type & other preferences: * click http://groups-beta.google.com/group/comp.lang.java.programmer/subscribe Report abuse: * send email explaining the problem to [EMAIL PROTECTED] Unsubscribe: * click http://groups-beta.google.com/group/comp.lang.java.programmer/subscribe ======================================================================= Google Groups: http://groups-beta.google.com
