> --
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
>
Happy New Year,
Kirk
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Not just the CPU! It really helps to be aware of how cores interact, caching, the memory controller, and how your operating system manages paging and virtual memory.
For an idea of this level of systems thinking, I still stand in awe of the Varnish architecture notes as one of the best examples of its kind: https://www.varnish-cache.org/trac/wiki/ArchitectNotesSure, there's value in knowing about pipelining, branch prediction, Compare and Swap vs Load Link/Store conditional, etc, etc. But you'll still gain more from familiarity with memory management and the garbage collector first.
Those ArchitectNotes are very interesting, but it seems difficult to
apply that on the JVM, where the maximum heap you can have seems to
depend more on physical than on virtual memory.
If I was writing a Java program that would otherwise be shifting
things between memory and disk how could I use his ideas?
Memory-mapped files?
If I was writing a Java program that would otherwise be shifting
things between memory and disk how could I use his ideas?
Memory-mapped files?
it's a big list but I think this year will be about how make Java play better with the CPU…. which implies, we'll need to learn more about how CPUs really work. it's a trend that has been emerging for a while but really only at a high fluffy handwaving level. I find that people are starting to ask the deeper questions, how is this really working? How can we tell? What adjustments can we make to increase cooperation between app and CPU?
yes indeed… we are being abstracted further and further away from the hardware and that generally has been a good thing. That said, many of us are not simply drivers of a car, we want/need to know these things so we can get more out of the car. So, you will see more people bounce between high level abstractions, which I love and understanding the implications of using those abstractions where the rubber meets the pavement. Anyways, my comment comes from observation, what interesting people are talking about. Last year cloud dominated.. and that's not going away… but this year I hear more interest in hardware….
People just learning more about the tools of our trade…
Happy New Year!
-Kirk
Or replace the Ant build with a Gradle build -- for which the control
file will likely be hugely smaller.
Surely adding dependencies should only be done if it means lumps of code
can be removed due to use of the dependency?
[JodaTime/JSR310 cf. https://github.com/ThreeTen/threeten is a special
case because the stuff in the JDK is know to not be adequate to the
task.]
> Also, browse the javaranch.com forums for the latest collective wisdom
> about which books and mock tests are best for the certification exam.
> I don't even really think the exam helps a resume all that much but
> you'll become an expert in language edge cases if you master the exam.
> It's helpful to be able to know at a glance whether a section of code
> will compile or not.
Is certification really a good idea? If SCJP (*) is going to be offered
as an example, then the only answer is "total waste of time".
(*) Not now Sun Certified Java Programmer of course, but Oracle
Certified Professional Java SE Programmer, which begs the question of
whether you can be an Unprofessional Programmer, and of course that
JavaME, JavaSE and JavaEE are so different, they needs separate exams.
Hummm... I think I spot Oracle milking the certification gravy train.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Project Coin is no more. By design. It was a project with a time limit. There is NO coin for 1.8 (the working title for the hypothetical java8 coin is "Coin - The Flip Side". It has been confirmed as 'will never be' by Joe Darcy who is responsible for it, because java 1.8 already has a full docket between jigsaw and lambda.
There IS a project coin mailing list which, with rare frequency, sees a feature request. These are basically squashed because they are rarely something that befits a coin request (coin is NOT just for 'hey, wouldn't this half-assed paragraph of an idea be fantastic?!?' - coin is: "This is good. See research here, here, and here. Here's a patch for javac. Here's a patch for the JLS. Here's conclusive proof that it won't affect backwards compatibility. Here's a 15 page diatribe on why its a good idea".There's an alternative to coin as well, and as it seems to be very close to what coin is trying to do I'm guessing there will never be another coin ever again. The thing is, I can't remember the name and some casual googling isn't helping me out here. It doesn't help that Mark Reinhold's blog is down right now. This alternative I'm talking about is a little more upfront about the idea that the submitter should be willing to hoist the trouble of writing the compiler patch and JLS update at the very least.