Really? Honestly curious what language you're working in. I do a ton of concurrent dev in Java and it is quite easy to write unit tests for. I think almost all of my concurrent code also abstracts most of the problems into a nice class hierarchy that encapsulates most of the threading related code anyways.
I'm not saying there aren't pit-falls but with something like http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601 as a reference it is really not that hard to right solid, unit testable, modular, multi-threaded code in Java. Though it really does help that as of JDK5 there are a lot of really nice concurrent constructs just built into the core API.
Uh, because they know that ads cannot be the income source forever? They need to find the next big thing and be there first or someone else will eventually beat them at their own game and then they'll go poof.
Yet another problem with being driven by quarterly profits instead of long term viability.
All depends on what you're doing with it. I work on an enterprise level webapp written 100% in java and we have deployments on Windows, Linux, Solaris and OSX-Server using the EXACT same code base and this is an app with over 1000 classes and 250k+ lines of code.
Your premise is equally as bogus. You're assuming that all our enemies could be made to fear us. If your living conditions suck enough it becomes hard to fear anything. What do you have to be afraid of? You likely have nothing of material value and little to no family to be held over you. Death / torture is the only thing they could be afraid of and so what? They are likely in a position where death is always a possibility anyways. How do you make someone with little or nothing to lose fear you?
It is a very well run educational summer camp at one of the better small engineering and sciences schools in the country. I did a summer of intro to CS classes while in high school and got a huge jump start for my college career. Also it is a lot of fun and a beautiful place to visit.
Many EDUs and other large business campuses use tri-gen plants and from everything I've seen they arguably are significantly more efficient per unit of input engery: http://en.wikipedia.org/wiki/Trigeneration
My wife and I both have written down our most commonly used passwords including our OSX Keychain passwords. These go into an envelope which has our signatures over the seal and then placed in a lockbox. If someone happened one either/both of us the details on these passwords are in our wills.
I have one of the higher end honeywell models (like $200 for the control panel + remote logic box) that has all sorts of fun options. Maximum adjustment increment, overall max/min settings, etc.
The biggest features I got it for are the external temp sensor which the thermostat uses to adjust the humidifier run time to avoid condensation in the winter and the smart recovery. The thermostat uses a combination of outside + inside temps and some recent historical data (how fast did the house cool down or heat up) to get to a specified temp at the specified time. So if I set it for 55 at night and want it to be 67 at 7am the thing just figures out what time it needs to kick on the heat in the morning so that at 7am the house is at 67. Wonderful feature if you live in the Midwest and you'd have to reprogram a simpler thermostat every month to get the same behavior.
As the other reply alluded this isn't a JVM problem but a problem with poorly written libraries. If a library sticks something in a ThreadLocal, creates a Thread, registers a JDBC driver, or several other tasks using classes from the webapp class loader and then DOESN'T CLEAN THEM UP when the webapp context is destroyed you get a ClassLoader leak. Just like any other Java memory leak it stems from having classes in the loader still reachable from the GC root.
Tomcat has made some great changes to their webapp classloader to watch for this bad behavior and forcibly remove/cleanup these references when a webapp shuts down, solving this problem in many cases.
Never frees... unless you are using the CMS collector (any app that does that much class loading/creation/unloading is likely a great candidate for CMS) and you turn on CMSClassUnloadingEnabled in which case the JVM unloads Class objects which are NOT in use just fine.
It isn't slowing down to much and stopping the engine (stalling)
Isao is right on, any modern car (not sure when it started) simply turns off the injectors if it is in gear and the car's momentum is making the engine turn. The alternator and all the accessories are still running fine since the engine is being turned by the wheels, no fuel is being provided to the engine.
Its really easy to tell when the ECU on my outback does this by listening and watching the MPG readout. When I start coasting down a hill while in gear and the clutch engaged you can hear the engine sound change as the fuel shuts off and the MPG readout goes to all 9s.
In short, don't coast in neutral, the ECU is smart enough to save you gas when you coast in gear.
So you have no snow cover in the winter? Not being to flippant, just curious how big of a band of the US has cold enough weather to require heat but not enough snow to generally have your roof be white all winter anyways?
I had the same question but it is very well addressed in the PDF:
During operation, these two flat surfaces are a separated by a thin (~0.03 mm) air gap, much like the bottom surface of an air hockey puck and the top surface of an air hockey table. This air gap is a hydrodynamic gas bearing, analogous to those used to support the read/write head of computer disk drive (but with many orders of magnitude looser mechanical tolerances). Heat flows from the stationary aluminum base plate to the rotating heat-sink-impeller through this 0.03-mm-thick circular disk of air. As shown later in Figure 18, this air-filled thermal interface has very low thermal resistance and is in no way a limiting factor to device performance; its cross sectional area is large relative to its thickness, and because the air that occupies the gap region is violently sheared between the lower surface (stationary) and the upper surface (rotating at several thousand rpm). The convective mixing provided by this shearing effect provides a several-fold increase in thermal conductivity of the air in the gap region.
The PDF also goes into how this tech could have serious applications in things like home AC and refrigerator heat exchangers as well.
It is completely up to the site serving the resources. A quick look unsurprisingly shows twitter not being stupid about it and setting the correct headers to get the browser to cache resources served over HTTPS for as long as the browser can. Here are the response headers from getting their logo over HTTPS:
Date Wed, 16 Mar 2011 14:52:00 GMT Content-Length 1159 Content-Type image/png Etag "c53472495d431cceef1c715732db12c9" Expires Wed, 18 May 2033 03:33:20 GMT Last-Modified Tue, 15 Mar 2011 21:20:55 GMT
Note that it provides both an Etag and a far-future Expires date.
The problem is TechWorld having no idea what this tool is for. The announcement by Google http://google-opensource.blogspot.com/2011/02/contracts-for-java.html never mentions the word "buffer" and accurately describes this as a tool for pre/post validation of method arguments and return values. Some how TechWorld decided to tie in JVM level buffer overflow issues with a pure Java DbC tool, anyone actually familiar with Java knows at a glance that the two are unrelated.
I think that is a poorly written summary. You can't (in pure java and ignoring JVM bugs) overflow buffers. You can however forget to do sanity checking on inputs based on the business rules of your app. That is where this will help. Codifying even simple things like "The argument should never be null" in an annotation on the interface definition helps both document and consistency for implementations of that interface.
There have been several projects that have tried to do this before but the developers never saw it through. When annotations were added in JDK5 this was one of the features I've been looking for. Being able to define invariants on the interface will make implementations much more safe and consistent!
If external entities knowing that big random strings are used as passwords and sudo is used for doing things as root is viewed as a security problem by my employer I believe I have bigger problems.
Joda actually provides their own TZ update mechanism: http://joda-time.sourceforge.net/tz_update.html
Joda already provides their own TZ update mechanism: http://joda-time.sourceforge.net/tz_update.html
Also anyone NOT using Joda for dates/times in Java really needs to come to the light and experience the wonders of a well designed API.
Really? Honestly curious what language you're working in. I do a ton of concurrent dev in Java and it is quite easy to write unit tests for. I think almost all of my concurrent code also abstracts most of the problems into a nice class hierarchy that encapsulates most of the threading related code anyways.
I'm not saying there aren't pit-falls but with something like http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601 as a reference it is really not that hard to right solid, unit testable, modular, multi-threaded code in Java. Though it really does help that as of JDK5 there are a lot of really nice concurrent constructs just built into the core API.
Uh, because they know that ads cannot be the income source forever? They need to find the next big thing and be there first or someone else will eventually beat them at their own game and then they'll go poof.
Yet another problem with being driven by quarterly profits instead of long term viability.
Most of the places I've been to in the US use wood frames for houses with maybe a few steel support beams for long open spans
All depends on what you're doing with it. I work on an enterprise level webapp written 100% in java and we have deployments on Windows, Linux, Solaris and OSX-Server using the EXACT same code base and this is an app with over 1000 classes and 250k+ lines of code.
Java has gotos:
loops:
for (int i = 0; i < MAX_I; i++) {
for (int j = 0; j < MAX_J; j++) {
break loops;
}
}
Your premise is equally as bogus. You're assuming that all our enemies could be made to fear us. If your living conditions suck enough it becomes hard to fear anything. What do you have to be afraid of? You likely have nothing of material value and little to no family to be held over you. Death / torture is the only thing they could be afraid of and so what? They are likely in a position where death is always a possibility anyways. How do you make someone with little or nothing to lose fear you?
As for the Michigan Technological University program here is more info: http://youthprograms.mtu.edu/
I went there in early high school for some of the CS camps and came away with a lot of interest and a great head start for college.
I was just going to point about Michigan Tech's Summar Youth Program: http://youthprograms.mtu.edu/
It is a very well run educational summer camp at one of the better small engineering and sciences schools in the country. I did a summer of intro to CS classes while in high school and got a huge jump start for my college career. Also it is a lot of fun and a beautiful place to visit.
Citation?
Many EDUs and other large business campuses use tri-gen plants and from everything I've seen they arguably are significantly more efficient per unit of input engery: http://en.wikipedia.org/wiki/Trigeneration
I think the concern is about being forced to reveal what you've written down while still alive.
My wife and I both have written down our most commonly used passwords including our OSX Keychain passwords. These go into an envelope which has our signatures over the seal and then placed in a lockbox. If someone happened one either/both of us the details on these passwords are in our wills.
I have one of the higher end honeywell models (like $200 for the control panel + remote logic box) that has all sorts of fun options. Maximum adjustment increment, overall max/min settings, etc.
The biggest features I got it for are the external temp sensor which the thermostat uses to adjust the humidifier run time to avoid condensation in the winter and the smart recovery. The thermostat uses a combination of outside + inside temps and some recent historical data (how fast did the house cool down or heat up) to get to a specified temp at the specified time. So if I set it for 55 at night and want it to be 67 at 7am the thing just figures out what time it needs to kick on the heat in the morning so that at 7am the house is at 67. Wonderful feature if you live in the Midwest and you'd have to reprogram a simpler thermostat every month to get the same behavior.
As the other reply alluded this isn't a JVM problem but a problem with poorly written libraries. If a library sticks something in a ThreadLocal, creates a Thread, registers a JDBC driver, or several other tasks using classes from the webapp class loader and then DOESN'T CLEAN THEM UP when the webapp context is destroyed you get a ClassLoader leak. Just like any other Java memory leak it stems from having classes in the loader still reachable from the GC root.
Tomcat has made some great changes to their webapp classloader to watch for this bad behavior and forcibly remove/cleanup these references when a webapp shuts down, solving this problem in many cases.
Never frees ... unless you are using the CMS collector (any app that does that much class loading/creation/unloading is likely a great candidate for CMS) and you turn on CMSClassUnloadingEnabled in which case the JVM unloads Class objects which are NOT in use just fine.
It isn't slowing down to much and stopping the engine (stalling)
Isao is right on, any modern car (not sure when it started) simply turns off the injectors if it is in gear and the car's momentum is making the engine turn. The alternator and all the accessories are still running fine since the engine is being turned by the wheels, no fuel is being provided to the engine.
Its really easy to tell when the ECU on my outback does this by listening and watching the MPG readout. When I start coasting down a hill while in gear and the clutch engaged you can hear the engine sound change as the fuel shuts off and the MPG readout goes to all 9s.
In short, don't coast in neutral, the ECU is smart enough to save you gas when you coast in gear.
Man I wish I had mod points. +1
So you have no snow cover in the winter? Not being to flippant, just curious how big of a band of the US has cold enough weather to require heat but not enough snow to generally have your roof be white all winter anyways?
I had the same question but it is very well addressed in the PDF:
During operation, these two flat surfaces are a separated by a thin (~0.03 mm) air gap, much like the bottom surface of an air hockey puck and the top surface of an air hockey table. This air gap is a hydrodynamic gas bearing, analogous to those used to support the read/write head of computer disk drive (but with many orders of magnitude looser mechanical tolerances).
Heat flows from the stationary aluminum base plate to the rotating heat-sink-impeller through this 0.03-mm-thick circular disk of air. As shown later in Figure 18, this air-filled thermal interface has very low thermal resistance and is in no way a limiting factor to device performance; its cross sectional area is large relative to its thickness, and because the air that occupies the gap region is violently sheared between the lower surface (stationary) and the upper surface (rotating at several thousand rpm). The convective mixing provided by this shearing effect provides a several-fold increase in thermal conductivity of the air in the gap region.
The PDF also goes into how this tech could have serious applications in things like home AC and refrigerator heat exchangers as well.
It is completely up to the site serving the resources. A quick look unsurprisingly shows twitter not being stupid about it and setting the correct headers to get the browser to cache resources served over HTTPS for as long as the browser can. Here are the response headers from getting their logo over HTTPS:
Date Wed, 16 Mar 2011 14:52:00 GMT
Content-Length 1159
Content-Type image/png
Etag "c53472495d431cceef1c715732db12c9"
Expires Wed, 18 May 2033 03:33:20 GMT
Last-Modified Tue, 15 Mar 2011 21:20:55 GMT
Note that it provides both an Etag and a far-future Expires date.
The problem is TechWorld having no idea what this tool is for. The announcement by Google http://google-opensource.blogspot.com/2011/02/contracts-for-java.html never mentions the word "buffer" and accurately describes this as a tool for pre/post validation of method arguments and return values. Some how TechWorld decided to tie in JVM level buffer overflow issues with a pure Java DbC tool, anyone actually familiar with Java knows at a glance that the two are unrelated.
I think that is a poorly written summary. You can't (in pure java and ignoring JVM bugs) overflow buffers. You can however forget to do sanity checking on inputs based on the business rules of your app. That is where this will help. Codifying even simple things like "The argument should never be null" in an annotation on the interface definition helps both document and consistency for implementations of that interface.
There have been several projects that have tried to do this before but the developers never saw it through. When annotations were added in JDK5 this was one of the features I've been looking for. Being able to define invariants on the interface will make implementations much more safe and consistent!
If external entities knowing that big random strings are used as passwords and sudo is used for doing things as root is viewed as a security problem by my employer I believe I have bigger problems.