World-writable memory on Samsung Android phones
Posted Dec 21, 2012 17:18 UTC (Fri) by khim
In reply to: World-writable memory on Samsung Android phones
Parent article: World-writable memory on Samsung Android phones
There are no guarantees at all in the language specification regarding when the VM will choose to allocate memory on the OS or C library level (nor should there be). Thus, you cannot be sure that anything you choose to do, or not do, in Java will or will not allocate memory on that level, though there are things you can do to roughly influence patterns of allocation and allocation rates.
Right. That's serious problem with Java and that's why I'm not big fun of this crazy language. However if you are Java programmer and you claim if you know how to use the beast then you must know how to use it in real world and not just in the programming contests —and that means you should understand when real-world implementation are likely to need memory and when they tend not to need it.
A JRE can legitimately start thrashing or run out of OS-level memory (and get killed or throttle itself) while executing nothing on the bytecode level but a loop which adds two numbers together.
Not all JREs do that. Aforementioned JavaCard JRE does not. And this problem is generally way, way, WAY too deep to discuss when we are talking about simple mundane tasks.
But if the candidate wants to raise it and spend his valuable time discussing it—who I am to object? Just like with real work: you are free to discuss hypothetical problems with JVM, JRE and Intel's microcode when you are asked to create couple of simple forms, but in the end you must provide code in reasonable time and of reasonable quality or else your are not very useful, right?
So you must define what you mean when you say 'without using additional memory', or you should expect to be misinterpreted.
Absolutely not. Interview process imitates work process in miniature. Someone who's genius and can solve any problem if you'll manage to formulate it precisely enough but will write code which will destroy your whole project if you'll miss one minute detail is someone who's just to dangerous to have around.
Yet you just said 'memory' and expected us to tell by telepathy which one you meant.
No telepathy, just common sense. You are correct that the task is not precisely formulated, yes. But that's half of the point! Your co-worker (and thus any good candidate) should catch cases where task is not defined precisely enough but s/he should not exhaust you with bazillion questions. If you need to spend two days to write precise spec for the task which only needs two hours to implement then you are better off without such a co-worker, right.
In this particular case the good approximation will be "no additional memory in computer science sense" (that is: you only care about memory explicitly allocated by your program, but don't care about JIT details), but if you can meaningfully offer some other idea—that'll give you bonus points. When someone applies his deep knowledge of JVM, JRE, Linux or any other technology to try to solve the task—that's good, it can only be commended, when someone tried to use the same knowleadge to screwup his coworkers… sorry, this something we don't need here (and I doubt there are companies who would want such behavior).
Oh, the second half of the point is the question is the ability to actually code solution for the agreed-upon task. It may be slightly different depending on the discussion, of course.
to post comments)