Linked by theuserbl on Sun 10th Jul 2011 18:48 UTC
Java "After an initial round of testing we've declared build 147 to be the first Release Candidate of JDK 7. There are only thirteen changes in this build. Over half of them are administrivial updates that don't affect the actual code; the remainder are true showstoppers, including several hard VM crashes and a JIT correctness bug identified by an Eclipse unit test. If no new showstopper issues are reported, and if JSR 336 and the component JSRs pass their Final Approval Ballots in the JCP, then this will be the GA build for release later this month per the schedule posted back in January."
Thread beginning with comment 480238
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: great
by noisedeli on Mon 11th Jul 2011 04:36 UTC in reply to "RE[3]: great"
noisedeli
Member since:
2011-06-29

Agreed. I've had Tomcat applications run for 6 months without a restart - while in moderate usage. I am a Java developer, so I'm biased, of course.

You may want to look at the application itself. The biggest reason I've seen that any Java web application eats up memory/resources is not closing connections to external resources (i.e. databases).

Replacing your architects is a good start here. Anyone called an "architect" should be able to figure out your issues in 2 days, tops. But I guess it's easier to bash Java itself.

Reply Parent Score: 2

RE[5]: great
by WorknMan on Mon 11th Jul 2011 05:30 in reply to "RE[4]: great"
WorknMan Member since:
2005-11-13

Replacing your architects is a good start here. Anyone called an "architect" should be able to figure out your issues in 2 days, tops. But I guess it's easier to bash Java itself.


Well, we've got perl apps that run side-by-side along with the java ones, and never have any trouble with those. It's only once the 'legacy' perl code gets rewritten to java (I assume because of java's multi-threading capabilities) does the trouble begin.

But who knows, you guys may be right. I don't work on the dev team - I'm just the grunt that gets paged at 3am every time one of those f**king apps decides to go on strike. So, I just call 'em like I see 'em. I've seen so many badly written apps in java, both on the server and desktop, yet it always seems to be the developers' fault every time this happens. Maybe other languages make it just as incredibly easy as java to write apps that run like dogshit. *shrug*

Edited 2011-07-11 05:31 UTC

Reply Parent Score: 2

RE[6]: great
by JAlexoid on Mon 11th Jul 2011 09:22 in reply to "RE[5]: great"
JAlexoid Member since:
2009-05-19

Long running Perl apps?!?!?! WTF? The place you work at should sue the developers of those apps for intentionally obfuscating the source code.

But sure... Call it like you see it. Now let me call it how I see it.
Visa's transaction handling applications have uptimes in months. Tel-co billing applications are under 90% average load and are restarted once per month for deployment or hotfixes. My own "poor little app" is used quite heavily and runs on a server with 1GB or ram. While mailinator works with Java for an incredible amount of time...

Reply Parent Score: 2