Detlev Beutner

Ranch Hand
+ Follow
since Jul 13, 2001
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Detlev Beutner

Hi Tanveer,

you can use a ByteArrayOutputStream as the wrapped OutputStream, and afterwards, call toString on the baos.

Hope it helps
Detlev
[ June 29, 2005: Message edited by: Detlev Beutner ]
12 years ago
Hi Terry,

I have not seen this before -is it new for JDK 1.5?



Yes.

My guess is that it is setting up the HashMap to handle String, Object value pairs.



Rrrighty :-)

Is this done for performance?



No, for type-safetyness as well as for the convenience of the developer.

Can someone point me to a link where I can read up on this?



See this info for some examples.

Hope it helps
Detlev
12 years ago
Hello Baka,
at a first glance, it seems to me that there must be something wrong with the bean in the session (that means, the bean you have filled before just is not in the session). With this, the <jsp:useBean> tag constructs a new bean, sure with an empty "Filename" (means not "empty" but null).
This is why the null is returned.
The JasperException I do not know, but there for sure is some problem with your bean definition - "Nothing special." is not quite true: A bean member starts with a lower case letter, so it must read "id" instead of "ID", "filename" instead of "Filename" and "extension" instead of "Extension". This at least differs from bean syntax.
With this together, all should work right, even if you still have the job to determine why there is no bean in your session when you expect it to be there.
Hope it helps
Detlev
14 years ago
JSP
Hello Davis,
I think you want to get back: 11, 9, 4, 16, 11, 9, 0, 0 etc.?!
Then here comes your code...

Hope it helps
Detlev
14 years ago
Hello,
as far as I understand you, you got the SCJP in June, but with (in your eyes) a bad result. Now asking if you should try it again or hunting on SCWCD?
I would say there is almost no sense in doing the SCJP again. If you want to present the exam for a company, you present the exam, not the concrete result.
I think it would be *possible* (why not, Sun would just earn some extra money for it), but that's all...
Preparing for SCWCD at least would bring some extra knowledge for you, so this should be the better decision. And if you want to get a better result, just prepare better this time :-)
Hope it helps
Detlev
Hello Dave,
casting an object does not mean to change the class-type of the object. It only says to the compiler: "Even if you cannot see that this object I want to use is an instance of class C, I assure you, at runtime, it will be." That's all.
So one of the most common uses of casting is working with the objects of a collection, for example of an ArrayList. If *you* know that in the ArrayList there are only, let's say String objects, you tell the compiler by casting that the following operation is allowed:

Without the cast, the trim method would not be allowed, because from the sight of the compiler, in an ArrayList there are only "Objects".
So in your example the cast is only to irritate one. r is an instance of Runtime, and because Runtime extends class Base, r is an instance of Base (in the sense of instanceof), too. But: The method wich is called depends on the runtime type (this is why the class is called runtime, knick knack), so: on the type r.getClass() would return. And that is, no matter if you use the cast or not - Runtime.
So it's 10,10.
Hope it helps
Detlev
Hello Hue Cheng,
it's getInitParameter() on the ServletConfig object (retrievable via getServletConfig()).
Hope it helps
Detlev
14 years ago
Hello Jim,
I also prefer to control the buffer by myself, but indeed it does not (or seldom) matter if you prefer to buffer the input by yourself or if you decide to take a BufferedInputStream. It "looks" faster if you have your own buffer (in the code, you "see" catching some thousand bytes at one time), but if you read from a BufferedInputStream, it has done the same before and catching the bytes works in memory, so the result normally is the same.
Just for clarification,
hope it helps
Detlev
Hello Vlad,
I don't know how the blocking now arises. At least, you could make your code more nice; probably this will not effect the problem, but first it could make it easier to understand the problem while debugging, second it could be nice for you to learn better style:
You will have noticed that you have twice a similar line with read() and twice a similar line with write(c). This should be enough reason to clean up the code. So, how to do this? Ask yourself: What *has* to be done (answer: the program will have to read() at least once). This results in the fragment

(Look at the spaces beneath "="... Java Coding Conventions...)
Ok, how many times has this to be done? As long as the return value is not equal -1. And what has to be done with the return value? It should be written to your charArrayWriter. BUT! Not in the case when it is -1 (this is an error in your code)! Leads directly to:

Hope it helps
Detlev
Hello Lakshmi,

"What does signature mean"


The JLS tells you...

8.4.2 Method Signature
The signature of a method consists of the name of the method and the number and types of formal parameters to the method.


So why is [a] correct? Because an instance method cannot override a static method. And why not? Because the term "override" really does not work here. A static method is a method without an instance context. If you would try to override such a method (without being static), you try to bring in an instance context, which the "overridden" method does not know. So it makes really no sense, because one cannot call it "overriding".
Hope it helps
Detlev
Hello Pradeep,
shorthands: No.
But: There are some ports from JUnit to C++: CppUnit and unit++.
Hope it helps
Detlev
14 years ago
Hello Vlad,
the problem is the use of the method "available" (please, read the apidoc). This returns 0, when there is no byte to be read *without blocking*. So it is possible that the underlying InputStream is not empty, but the BufferedInputStream is "empty so far" (waiting for the next bytes).
So, please check the read-method if it is returning -1 (now the end of the stream has been reached).
Hope it helps
Detlev
Hello Asim,
I don't know if it is a *must* for you to use the native DLL's. If not, there a some Java-barcode-solutions on the market. One of the more popular open source solutions is Barbecue.
Hope it helps
Detlev
14 years ago
Hello Nilesh,
I think this article is somehow the "standard" of explaining this.
Hope it helps
Detlev
14 years ago
Hello Vishnu,
I'm not sure, but I hope you are thinking of somethng like this:

In this case, please refer to the API-DOC for further information.
Hope it helps
Detlev
14 years ago