Nick Widelec

Hi all,

Following the instructions in the documentation here I set the run-jrebel.cmd as follows:

@echo off
set JAVA_OPTS=-javaagent: c:/jrebel/jrebel.jar -Xms256m -Xmx512m -XX:MaxPermSize=256m %JAVA_OPTS%
call "%~dp0\run.bat" %*

jrebel.jar is exactly there, however still does not work and I get the error message:

Error opening zip file or JAR manifest missing :

I am using jdk6 and jboss 4.2.3. Thanks in advance.

Winston Gutkowski wrote:

Nick Widelec wrote:So JavaScript is run server-side or client-side? You say no client-side activity. But the above Jeanne's response seems to say the other way around.

I think you misinterpreted what Bear said (it actually took me a couple of scans too ).

What he said was that "no JavaScript means no client-side activity" - ie, without JavaScript, there won't be any client-siide activity.

And what Jeanne was saying was that you want straightforward stuff like field validation to be done on the client side. So, putting those two things together, it makes sense for a page that DOES want client-side activity (eg, for validation) to include JavaScript.

Does that make more sense?

Winston

Thanks Winston,
That was exactly the line I got confused with. Now is clear thanks.

Bear Bibeault wrote:No JavaScript means no client-side activity, regardless of how the HTML page was generated.

So JavaScript is run server-side or client-side? You say no client-side activity. But the above Jeanne's response seems to say the other way around.

Jeanne Boyarsky wrote:Suppose you want to validate the user entered valid characters in a date, name, phone #, etc and the format is valid. To do this with just JSP, you'd have to go to the server to do all this validation and make the user wait. Which is poor usability.

Similarly, many dynamic elements of a page require JavaScript. So yes, you COULD develop a page without JavaScript. But it would be like the pages circa 1995; not what users have come to expect.

Thanks Jeanne,

I see that there are quick tutorial to get the hang of it. http://www.youtube.com/watch?v=_cLvpJY2deo (JavaScript in 30 minutes) the basics.

Jeanne Boyarsky wrote:Nick.
JavaScript is used in the browser regardless of what back end is used. So JavaScript should be required for both JEE and CGI (and .NET and ...) back ends.

You might be interested in reading about the polyglot programmer. It's a good way to describe that there is no such thing as a "Java" programmer. You must know SQL, HTML and JavaScript at a minimum. And often other languages as well.

Can you not get away with jsp? What does JavaScript give you more?

Thanks in advance.

Hi everybody,
I have seen many job ad. requiring JavaScript for JavaSE/EE jobs... I wonder why since jsp/servlet should be favourable instead of CGI.
Thanks in advance.

Hi,
In many job ad. (someone requiring SCJP) I have found as a requirement:

General knowledge of programming.

What does it exactly mean? for, if-else etc..? or algorithms and bigO notation and stuff?

Thanks in advance.

Alam Ameghino wrote:I think that my poor ingles is a problem in this case. Sorry.

See friend,

From Kathy and Bert's book

Page 392. Title: Don't use assertions to validate arguments to a public method.

So, it is not correct:
public void m1(String s) { assert s != null; // // it is no correct }
Page 393. Title: Do use assertions to validate argument to a private method

So, it is correct.
private void m2(String s) { assert s != null; // it is correct }
But, What happen when in a private method we are validating an argument that belong to the previous public method? The argument is the same, the same object in both.
public void m1(String s) { assert s != null; // it is not correct m2(s); } private void m2(String s) { assert s != null; // IS IT CORRECT? }

Thanks Nick.
Sorry if I am not being clear.

To me line 7 is always correct, at most it would be a wrong usage of the private helper method in line 3 IF line 2 was absent. Although line 2 is NOT correct, it checks whether the argument is null or not. Past line 2 and now being in line 3, m2(s) method is just a postcondition. In order to consider a post condition as the name say, you have to consider the Runtime process of the code.
I do agree that method declared in line 1 m1 does a wrong usage of assertions. However if you take line 3 per se, in that context (after line 2 the argument cannot be null), there is nothing wrong in checking that post condition. If you removed line 2 and the method m1 was only like :

public void m1(String s) { m2(s);//incorrect it's directly checking the argument. }
So my point is that line 2 is incorrect but line 3 is ok if put after line 2.

This is my point of view considering what a postcondition is.
Waiting for other opinions on the issue.

Alam Ameghino wrote:I know thtat assertions work only in runtime, but you must say if they are appropiate or not in compile-time.

You don't need run a program for know if assertions are appropiate or nor!

I do not think so, to enforce my point I again restate that it's perfectly fine using side effects (hence runtime behaviour) within assertions.
And to give credit to what I say I quote from the link I have already mentioned above

As a rule, the expressions contained in assertions should be free of side effects: evaluating the expression should not affect any state that is visible after the evaluation is complete. One exception to this rule is that assertions can modify state that is used only from within other assertions. An idiom that makes use of this exception is presented later in this document.

The exception that the quote talks about, it's exactly the case we have with line 2 and 3. (There is a side effect within assertions)
Bottom line: line 2 is incorrect, as it is not appropriate checking an argument in a public method, however line 3 per se is correct, it's just a postcondition depending on the result of another assertion.(which is acceptable)

If you say that it must be at compile time, please to quote your reference.

Alam Ameghino wrote:
Hi Nick, and again thanks!

Mmmmm, I am not agree..

You must say if assertions are appropriate or not in COMPILE-TIME, no in RUNTIME-TIME.

The assertions work only at Runtime (if enabled)... at compilation time the compiler just ignore it.

Again the purpose of assertions is at RUNTIME-TIME, to enforce the idea: it throws an AssertionError which works as a RunTimeException, nothing is checked or done at compile time.

Therefore saying that assertions are appropriate at Compile Time there is no sense.. further in the link I above posted is also shown that it's legal using a kind of flow control with assertions enabled as long as there won't be any side effect in the code itself (without assertions).

Alam Ameghino wrote:Nick, thanks for the link and your answer.

But, I can not see the answer to me question in this link!

Where do you see the answer in the link?

Well, the thing is that when assertions are enabled and the the argument is null, line 2 will throw an AssertionError and line 3 will never get called.
On the other hand if the argument it's not null and the assertions are enabled, it will pass through line 3 and the argument now is assured to be not null by line2! so it is a postcondition in this sense, it further ensures the state (condition) of a field/value. Which is appropriate to do. (even in public methods)

Hi everybody,

Thanks to all the javaranch community for your support.
In order to prepare for the exam I studied the K&B book and integrated with the oracle tutorial available here.

Big credit also to Enthuware software which, other than being low priced and delivering super quality questions, is also a great learning tool per se.
I strongly reccomend this software in order to be prepared for the exam and at the same time understand the concept as all the question have detailed explanation very well written. (if you do not understand something you can clarify in the forum which will promtly reply usually within max 24 hour).
I also used nikojava.wordpress.com/.../free-scjp-mock-exams/ that for generics and multi-threading topics is very good. (even if it's related to OCPJP 6)

That's all super happy about it, thanks again to everybody especially to Jeanne Boyarsky, Henry Wong, Paul Clapham and last but not least super Paul Anilprem.

Alam Ameghino wrote:Thanks for response Souvik!

I believe the same, but I am not sure.

Someone knows exactly what is the answer?

I think it's ok as it's checking a post condition, it's allowed even in public methods.
Check out postconditions here http://docs.oracle.com/javase/1.4.2/docs/guide/lang/assert.html#usage-conditions

Hi everybody,

Does deserializing an object in another JVM call the static initializer?
It does not within the same JVM as the class is already loaded while serializing it, however what about in another jvm? Would the static initializer get called?

Thanks in advance.

So guys any new opinions concerning this topic? It's just that tomorrow I have the exam and I would hate missing a score on this.
Cheers.