marton nagy

Greenhorn
+ Follow
since Jun 07, 2013
marton likes ...
Notepad
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
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by marton nagy

Hi,


Ive recently started experimenting with flex4.7+remoting+blazeds4+glassfish4.

Ive just noticed, that when i use a session scoped ro from the flex side, even if i programatically invalidate the FlexSession ( FlexContext.getFlexSession().[timeout()|invalidate()] ) the next call from the client side will be handled by the exact same ro instance.

-when i check out the sessionId from the FlexSession, it changes after invalidation, but the ro instance stays the same
-when i close the browser(with the flex app), and reopen it, the next ro-call will handled by an another instance


isnt this behavior the application scope behavior?
shouldnt get after session invalidation the ro instance destroyed?





thank you for your help in advance!
4 years ago
Hi Ranchers,

phew...done

Many and big THANKS to Bert and Kathy! I think pearson's income would double without You, Guys

how did i prepare:
-K and B study guide (2x read)
-all tests from K and B study guide (not after each chapter, but at the and at once) 2 times
-all test from K and B practice exam book 1 time each
-every time completed a test, checked the faild ones, uneasy ones, study those fields again, write programs etc.
-write few hundred mini programs
-checked out the api carefuly, and memorize
-stick to what Kathy and Bert suggests

suggestions and opinions:
-if you are unsure bout something: write a program, test it out. every time.
-1z0 851 is far easier than the tests in those books, on those test i could only touch 80%, and ive also failed on the hardest one
-oracle claims in 1z0 851 are no more time consuming questions, no serializations, 60 questions, 150min time, over 61% passing. i confirm that.
-dont feel bad about the time, to be honest i could finish only 1 or 2 test from the books in-time ;) but at the real exam i had ~40 minutes left AFTER checking out every marked question (the exam-app is a big help too). so no hurry, take your time on the real exam.
-the study guide covers about 95% of the api questions, so maybe it is worth study the marked apis bit further...(for example: Thread.interrupt, NumberFormat.format(Object), System.getProperty, System.getenv() )
-dont rush tests from the books, stick to suggestions at the recommended plan at the result analysis (i think takeing again tests is not a really good idea, iv tried with the study guide tests, and well it was a great success, can build some confidence but for me it was little odd seeing those questions i know ive answered once, and ive also see the correct answare, and your brain -that tricky bastard- begins to think more and more about "what WAS the answer?" instead of "what IS the answer", which misses the point - the preparation)
-marker boards suck choose exam-centre where you can use paper and pen if you can (notice: on real exam you do not really need to draw and write much, ive used only 1 A4 board - wich is like 1 A5 paper page and pen :S - but ont mock exams i had to write a LOT)

i hope i could help a bit, and i wish luck to every future ocpjp

cheers
4 years ago
Hi Everyone,



gurpeet singh wrote:

consider option A The command for compiling is javac -d . -cp . Saturn.java . the classpath will be able to find Lunar.class but what about Module.class which is in controls.jar. how can A be correct ?



My Question is the same as above. Ive tested the exact same scenario, and in fact javac dont need Module.class file (or java file) to compile Saturn.java.
BUT: after ive changed Module from interface to class, and changed in Lunar the implements to extends, magically javac is no more happy compiling Saturn.java without Module.class (Saturn.java:5: cannot access apollo.modules.Module class file for apollo.modules.Module not found)
My problem is not this second situation, im fairly comfortable with that...but why javac dont need Module.class as it is an interface?

Can someone tell me what is going on here...?

V Sa wrote:Inner classes may not declare static members, but may inherit static members that are not compile-time constants. I do understand that there is no purely static way to access static members of non-static inner class. But what I am not able to understand is why then can that same non-static inner class inherit static members. Can anyone explain this?



I think static members and methods are bound to the class where those are defined. Thus inheriting such members only means access to the static members of that particular parent. (for example if Parent has a static int i=5; this value is attached to the Parent class. every child, who inherits this, ll have access to the SAME value, or: there are only one static field for all the instances of a class and instances of subclasses. so when one child instance says i++; an instance of parent ll see 6 from it then. unless redefined of course).
In this case, we got inner classes: concept is, those classes are bound tho the outer class, as inner class instances can only exists attached to an outer class instance. wich means no static at all, and these classes also cannot be referred as static, as you said. as i see it, those "inherited" static members simply belongs to the parent class.

V Sa wrote:Is there a purely static way in which these static members in Super class be accessed? (Didn't find it across the net )



As the inner class's inherited static members are the same as those from the parent, you can access them accordingly (ParentClass.staticMember parentClassInstance.staticMember) or with the instance static trick also via inner class member (innerClassInstance.staticMember)

it became a little long sorry, but my point is: static members belong to the parent class, innerclasses cannot have static members, innerclasses can inherit statics but those belong to other classes, therefore no need to access inner's statics

Hi Everyone,

my question is considering the "C" answer option.

the KandB book states:

"Some JVM's might not recognize ten distinct values. Such a JVM might
merge values from 1 to 10 down to maybe values from 1 to 5, so if you have, say, ten
threads each with a different priority, and the current application is running in a
JVM that allocates a range of only five priorities, then two or more threads might be
mapped to one priority."

what dosent mean (to me), that such a JVM is not possible, where all the 10 prio levels are mapped to 1 - such a JVM doesent use proirity at all (maybe on an older mobilephone implementation or some old ARM-JVM whatever). and in this case it is well possible thath the jvm decide at t1.start() "okay whatever i ll run t1-s run() til the and after i get back to you main()". What would mean in this case that t1 ll complete, and only after ll main()-s new mosey().run() start. And if such case could exists the answer C is no more right, isnt it?

i know it sounds little out-of-world-ish, but onestly i was really suprised to see this C answer as right, after ive read in the KandB book:
"In most JVMs, however, the scheduler does use thread priorities in one important
way: If a thread enters the runnable state, and it has a higher priority than any of
the threads in the pool and a higher priority than the currently running thread,
the lower-priority running thread usually will be bumped back to runnable and the
highest-priority thread will be chosen to run. In other words, at any given time the
currently running thread usually will not have a priority that is lower than any of
the threads in the pool. In most cases, the running thread will be of equal or greater
priority than the highest priority threads in the pool. This is as close to a guarantee
about scheduling as you'll get from the JVM specification"

but what the heck, ask the question directly to the JVM: System.out.print("as close to a guarantee"=="guarantee"); ;)

what do you think?


ps.: i give it a try to answare my own question as: as if a question ("...will probably run most...") mentions probably considering Thread-priorities scenario, you should treat statements about jvm and priorities without "usually" "in most cases" "as close to a" words, and deal with the situation in that fashion. We could call this "explicit thread priority uncertainty erasure". Sorry about that, just making fun, im really interested in any serious thoughts about that!!