Tom Tolman

It is under the WEB-INF folder structure. I was assuming I would place my html files in the same folder structures as the jsp files, but I guess this was an incorrect assumption.

By placing the file at the root (above WEB-INF) I have been able to get the url to work, this is great. (I utilized your context dependency:
<a href="${pageContext.request.contextPath}/Test2.html">Test2</a><br>

However now I am curious what the correct layout for the web pages are. That is to say, if I wish to have jsp and html files interleaved, what would be the correct layout to perform this?

For example, I am going have some of my web pages with pure content that is predetermined (html) and some that is dynamically created (with jsp). Should I have completely separate, but parallel files?

I am going to have sections of material (in html), broken up with quizzes on this material (created from jsp). So would I create something like:

Section1\Tutorial.html Web-INF\Section1\TutorialQuiz.jsp

For every single section? I had been planning on putting the html and the jsp in the same folder for the same content.

I am setting up a web service which will utilize JSP to create web content.

I have successfully installed and am utilizing the NetBeans IDE 4.1 with JSP- I can write jsp code and it is working properly.

However, when I link to an html page on the same site, the link does not work.

For example, my link is

<a href="/Test.html">Test</a><br>

My Test.html file is located in

Web Pages
WEB-INF
Test.html


When I run the application, it comes up with

type Status report

message /Test.html

description The requested resource (/Test.html) is not available.

Any ideas? Is there something I am missing?

Thank you

On the bottom of page 114 of HFSJ it says "The Http 1.1 spec declared GET, HEAD, and PUT as idempotents, even though you CAN write a non idempotent doGet() method yourself (but shouldn't). POST is considered idempotent by the HTTP 1.1 spec."

Then immediately it says "POST is not idempotent"

Is the first paragraph last line a typo, or is it that they are making a distinction between intention of server response vs the actuality of correct server response?

I want to use Vector2D in an applet. What do I need to install to get access to it, and how do I set the classpath variable to utilize it?

I know I need to import javax.vecmath.*;

but this fails with javac it says "does not exist"

Thanks for any pointers

(And on a related note...

- If I use this, can I distribute my applet and will it run everywhere? If so, does it "link in" the utilized vector2d code, and how does this work?)

I think that variables in general are normally allocated on the stack, not the heap, so they are not available for garbage collection. (When they go out of scope, they simply go away, like when a method returns). Now for the objects they point to- they are on the heap and subject to garbage collection.

So the static variables themselves, I don't know where they are, but I would suspect they are on the stack, in the "main stack frame" area which only goes out of scope when the program terminates, but I don't know this for a fact I am guessing.

Now the objects that a static reference points to could be in the heap, and available for garbage collection when that reference points to something new.

It prints out T1T1T3.

This is both what I expected, and what it did. Note however I wasn't so confident that I posted my response without trying it!

Anyway, why?


We create a new thread (new B(), "T1") which is called T1.

The run method is invoked (on a new stack) with the start call. This new stack, called T1, immediately creates an A and calls run. It does not create a thread, it just calls run, so there is no new stack frame. It is not a new thread, and prints out the current thread name T1.

Next, we create a new thread A, but again we do not call start. We call the run method on the thread. From the sun docs:

run()
If this thread was constructed using a separate Runnable run object, then that Runnable object's run method is called; otherwise, this method does nothing and returns.

So this calls the run method of A- which prints out T1- there is no new stack frame for T2. If you change it to a start() call you get T1T2T3, but since we didn't, we get T1.

Finally, we call the new thread correctly, and create a thread which gets its own stack frame with the start() call. When the run method is executed now it finds the new name of the thread T3.

The answer must be because float can not completely hold the bits of the integer. An integer is 32 bits, with a sign bit. A float is 32 bits stored in IEEE 754 standard. But just this fact alone should make you wonder: how is it possible a float can store the highest value of an integer?

The float needs to represent sign AND represent exponent. Those bits can't just be discarded to represent the exponent- they are still there. So it must throw out some bits (of precision) to make some room for the exponent, unless of course it can be represented exactly. But you already know it should be 111111111111111111 (it is the highest number) so what low bits can be stripped off? None.

If you want the details, drill into the format itself.

http://cch.loria.fr/documentation/IEEE754/

Your first question is a good question. It certainly won't compile if you take out the final on final int i.

I tried:

class outer { outer outerref; void keepval(int i){ class inner extends outer { final int j = i; void showval(){System.out.println (5);} } outerref=new inner(); }

And that doesn't compile either. I reasoned perhaps if you used the variable in the initialization (as opposed to within a method) it might feel comfortable with it since there would be no required later copy of it. No go.

I don't know where it stores it. One possibilty is it creates a member variable for all inner classes for final variables. Another possibility is that when it instantiates the code for the inner class it dynamically creates the value in the correct spot- this is pretty unlikely.

Try the following code out:

interface E { char v='v'; char w=A.echo('w'); } interface F extends E{ char x= A.echo('x'); char y= A.echo('y'); char z= A.echo('z'); } class A implements F{ static char echo(char c){ System.out.println(c); return c; } public static void main(String[] a) { System.out.println("Main"); A g=new A(); char q = x; System.out.println(v); char o = y; } }

I think it is because the n++ is a copy of the original value, while n[0]++ IS the actual value.

Java passes all things by value- the integer and the reference. The reference, when dereferenced, points to the original object which is incremented.

One way to look at it is that normally your code has a linear flow to it- one line executes, and then the next line executes. It always goes in order. It may branch, but the branches are determined deterministically by comparisons.

Now when you add a thread, there are two independent threads of execution which interact. A single line of code can execute, then the thread can switch, and this same line of code can execute again!

An int is a 32 bit value represented as 2's complement. Some simple values to MEMORIZE:

1 = 0x00000001 = 000000000000000000000000000001
-1 = 0xffffffff = 111111111111111111111111111111
0 = 0x00000000 = 000000000000000000000000000000

Now 6 is equal to 0x00000006 or
00000000000000000000000000000110 (4 + 2)
Invert this, and you get
11111111111111111111111111111001

What is this in decimal? Well, if you don't want to memorize an equation, walk through the negative numbers

00000000000000000000000000000000 = 0
11111111111111111111111111111111 = -1
11111111111111111111111111111110 = -2
11111111111111111111111111111101 = -3
11111111111111111111111111111100 = -4
11111111111111111111111111111011 = -5
11111111111111111111111111111010 = -6
11111111111111111111111111111001 = -7

Or if you prefer, you can memorize an equation- do you see the relationship between the above numbers and the positive numbers?

To go from negative to positive, you invert the bits and add one
To go from positive to negative, you invert the bits and add one (1 inverted is 11111111111111111111111111111110, and you need to add one to get to 11111111111111111111111111111111)

So now you are inverting the bits on the number six. You have not added one. If you did add one, you would have -6. So -6 missing 1 is -7.

I interpret "Exiting from a synchronized block." to mean that the thread exits from a block of code which has the lock on an object- thereby allowing other threads to access this objects lock (and execute synchronized blocks on it as well)

I don't interpret it to mean the program ends. Nor does it mean that the currently executing thread will necessarily suspend- why would it? What if you had a single thread application with lots of synchronized blocks in it- would the thread cease (for no other thread) simply because it had left a synchronized block?

A synchronized block does not imply anything about the thread being run. A thread can be put into a wait state even if it is holding object locks.

If you implement Runnable, you need to define the run, since the Runnable interface has an abstract method run.

However, Thread is not an abstract class, and does implement run. It calls the Runnable if it has one, or else does nothing and returns.

Therefore, you can extend Thread and not implement run, but it won't allow you to utilize it as a separate thread, but you can utilize the class normally.

From the java API start()Causes this thread to begin execution; the Java Virtual Machine calls the run method of this thread.

Thus, it will invoke the Threads run method. The Thread A has two potential run methods- the base class which will call start on Runnable B which prints B, and the derived class A which will call the run which prints A.

Which of these two methods will be invoked when the start method is called? It is bound dynamically, and actually is of type A, not Thread, so binds to the A method, and prints A.

Consider these as well:


This will print B.

Thread t = new Thread(new B()); t.start();

If you comment out this line:
//public void run() {System.out.print("A");}

Then B is printed. It is no longer being dynamically bound- the run method is not overridden.
[ September 24, 2004: Message edited by: Tom Tolman ]