Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Java's New G1 Collector Not For-Pay After All

kdawson posted more than 5 years ago | from the trial-balloon-popped dept.

Java 171

An anonymous reader writes "As a follow-up to our previous discussion, Sun appears to have quietly edited the Java 6u14 release notes language to say now: 'G1 is available as early access in this release, please try it and give us feedback. Usage in production settings without a Java SE for Business support contract is not recommended.' So does this mean it was all one huge typo? Or was Oracle/Sun tentatively testing the waters to see the community's reaction? In either case it's nice to see Java's back on the right path."

cancel ×

171 comments

Sorry! There are no comments related to the filter you selected.

Haha! (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28221125)

The arm is disbombed!

Wait what?

Right path? (5, Funny)

DoofusOfDeath (636671) | more than 5 years ago | (#28221165)

In either case it's nice to see Java's back on the right path.

Did kdawson even read the article before writing the summary? I don't see anything in the article about Java becoming more like Haskell!

Re:Right path? (0, Insightful)

Anonymous Coward | more than 5 years ago | (#28221189)

s/becoming more like Haskell/being scrapped/

Re:Right path? (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28221623)

In either case it's nice to see Java's back on the right path.

Did kdawson even read the article before writing the summary? I don't see anything in the article about Java becoming more like Haskell!

Fuck Java, it's a slow piece of shit and one vendor (Sun) has too much control over it anyway. Even niggers and dune coons know that! That's sayin something too because the niggers were stoneage primitives who didn't even have the wheel when the White Man found them and the dune coons are a bunch of savages who are so busy with their ages of blood feuds that they probably don't remember what they're fighting about anymore and are probably only still around because they have oil. So now niggers are a bunch of thug wannabes and dune coons gave us terrorism and anyone is surprised by that. Like I said Java is too goddamned slow.

Re:Right path? (1)

DoofusOfDeath (636671) | more than 5 years ago | (#28222025)

I want to mod that post "+1 funny because it's so -1 insane."

When will Taco finally implement complex-number mods???

Re:Right path? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28222157)

I want to mod that post "+1 funny because it's so -1 insane."

When will Taco finally implement complex-number mods???

He can't do that. The stoneage primitive niggers won't understand this complex-number mod concept cuz they didn't even invent the wheel on their own, remember?. The dune coons will think it's an insult to Allah because to them everything is an insult to Allah and will retaliate by raising the price of oil. And, Taco might implement that in Javascript and it has the word Java in it, so it must be slow.

But it could be! (5, Insightful)

BadAnalogyGuy (945258) | more than 5 years ago | (#28221171)

Garbage collection is an amazingly boring field of computer science. It's all about tracking references and trying to keep memory from filling up while also trying to keep the overall impact on the running system down. But as boring as it may be, it's also absolutely critical in today's interpreted languages.

Where Java really fails is in the inability to trust the finalize method. At least in C++, the destructor of an object is guaranteed to be called as soon as the object is deleted. Java has no such guarantee, so expecting an object to clean itself up once it goes out of scope is a fool's errand. It will get finalized eventually, but the lack of deterministic behavior in this critical part of the object lifecycle means that there is a very big chance that unacceptable delays may occur in practice.

Give me deterministic behavior over faster GC any day.

Re:But it could be! (4, Informative)

yacc143 (975862) | more than 5 years ago | (#28221335)

Deterministic behaviour => use reference counting. E.g. Python has it.

But the situation with C++ is not as rosy as you paint it.

E.g. there are no guarantee that destructors on static object will be called.
Nor are destructors called on longjmp.

Re:But it could be! (1)

codewarren (927270) | more than 5 years ago | (#28221379)

use reference counting != deterministic behavior

reference counting + any indirect circular reference == memory leak

Re:But it could be! (1)

DoofusOfDeath (636671) | more than 5 years ago | (#28221425)

use reference counting != deterministic behavior

reference counting + any indirect circular reference == memory leak

I disagree. The timing of when deletion occurs is still deterministic in such a case. It's just harder for programmers to notice. That causes its own problems, but nondeterminism isn't one of them.

Re:But it could be! (2, Informative)

tepples (727027) | more than 5 years ago | (#28221479)

use reference counting != deterministic behavior

reference counting + any indirect circular reference == memory leak

hybrid GC with both reference counting and mark and sweep for cycle detection == closer to deterministic than what Java offers in the good case (no circular references) while still correct in the bad case (circular reference becoming detached from main())

Re:But it could be! (1)

shutdown -p now (807394) | more than 5 years ago | (#28225225)

hybrid GC with both reference counting and mark and sweep for cycle detection == closer to deterministic than what Java offers in the good case (no circular references) while still correct in the bad case (circular reference becoming detached from main())

It still doesn't make sense in practice, because all bets are off. So long as there is any external references to your object, direct or indirect, you do not know whether it is a part of a cycle or not, and therefore cannot know whether its destruction will be deterministic or not. So you can't rely on it being deterministic in general.

So reference counting doesn't really buy you much there. However, it does introduce a significant performance hit [wikipedia.org] (this may sound surprising, but mark & sweep GCs actually get better average performance than reference-counting ones).

Re:But it could be! (2, Insightful)

bluefoxlucid (723572) | more than 5 years ago | (#28221493)

Reference counters have cycle detection. See Objective-C.

Re:But it could be! (1, Informative)

Anonymous Coward | more than 5 years ago | (#28221785)

Objective C (cocoa/openstep) reference counting does not have cycle detection.

Re:But it could be! (1)

ThePhilips (752041) | more than 5 years ago | (#28222135)

I find on Google mentions that Python which uses ref counting detects cycles.

I doubt Apple would bother including GC in Mac OS X 10.5 + Objective C 2.0 if it didn't work properly. More than that, documentation on developer.apple.com says that (manual) reference counting isn't compatible with auto GC, meaning that it's not really ref counting based GC. It is clearly states that ref counting and GC are mutually exclusive. Provided that Core Foundation already provides quite rich set of memory management facilities, I personally do not even think that GC is all that important to Cocoa applications. It is a mere utility, provided for convenience, as new generation of developers apparently fail at resource management. (Do not tell me: I know that GC makes life easier. But unfortunately I also have witnessed many occurrences when it can make life harder.)

Re:But it could be! (1)

multi io (640409) | more than 5 years ago | (#28224357)

I doubt Apple would bother including GC in Mac OS X 10.5 + Objective C 2.0 if it didn't work properly.

Parent was talking about ref counting, not GC. Apple bothered including GC in the ObjC runtime exactly because the reference counting they had before that had cycle detection issues (and it was harder to program to). In the commonly used terminology, GC and ref counting are different things.

Re:But it could be! (2, Informative)

shutdown -p now (807394) | more than 5 years ago | (#28225259)

I find on Google mentions that Python which uses ref counting detects cycles.

It does, though, as I understand, the behavior is the way it is mostly for backwards-compatibility purposes.

Guido once made a list of things that he considers "implementation details" for Python, and not guarantees of the language spec - meaning that alternative Python implementations could deviate on those points from CPython. Reference counting is on that list, and e.g. Jython and IronPython do not use it at all, relying strictly on tracing GCs provided by their respective VMs.

Re:But it could be! (1)

0xdeadbeef (28836) | more than 5 years ago | (#28221905)

Ref-counted Objective-C does not do automatic cycle detection. Garbage collected Objective-C is not based on reference counting.

Re:But it could be! (1)

ebuck (585470) | more than 5 years ago | (#28225287)

It it has cycle detection, then it's not "just" a reference counter. Probably it's a hybrid reference count / mark and sweep algorithm. The reference count lets you discard some of the objects quickly, while the mark and sweep lets you discard the circular references a little more slowly.

Even if Objective-C does not use a hybrid reference count / mark and sweep algorithm, it doesn't use a pure reference counting solution. If it did, then it would only have the number of times something was referenced, which cannot tell you the topology of the references, in the general case.

Re:But it could be! (2, Insightful)

Captain Spam (66120) | more than 5 years ago | (#28221527)

use reference counting != deterministic behavior

reference counting + any indirect circular reference == memory leak

That sounds pretty deterministic to me. Indirect circular reference == memory leak, all the time. You can count on that.

Re:But it could be! (0)

bluefoxlucid (723572) | more than 5 years ago | (#28221515)

Destructors on static objects don't make sense. Static objects are not dynamically allocated and cannot thus be freed.

Re:But it could be! (1)

ThePhilips (752041) | more than 5 years ago | (#28222289)

Probably you should RTFM, e.g. man atexit and man exit. Then on Linux compile a small program with static objects and run it under ltrace to see the truth of how it really works.

I did once had the unpleasant experience - debugging monstrous C++ applications, ridden with static objects, which depending on temperature outside of window and direction of wind was sometimes crashing during start-up. And quite reliably crashing during shutdown. (Redundant exception throwing (as modern OO programmer like it) and infamous "singleton" of the design patterns' hall of shame - and you have the sure recipe for a disaster.)

That's actually I personally never use static objects. Very few objects in a program have no dependencies. As soon as any static object has any external dependency or internal state which has to be persistent - forget about clean shutdown.

Re:But it could be! (0)

Anonymous Coward | more than 5 years ago | (#28223239)

'exit' is a system call that you shouldn't be using if you expect to cleanup resources. Return from main and your statics will be cleaned as expected. Since 'exit' is not part of the standard, you can't blame C++ when it doesn't clean up your statics.

Re:But it could be! (2, Insightful)

ThePhilips (752041) | more than 5 years ago | (#28224649)

'exit' is a system call ...

That was about where I stopped reading the comment.

The modern "high-level" programmers who do not understand (nor bother to try to) how their own programs actually work, fit with the system and how system is used to implement language features deserve no pity.

Go back to your Java cave.

Re:But it could be! (4, Informative)

tepples (727027) | more than 5 years ago | (#28221517)

Nor are destructors called on longjmp.

That's one reason why setjmp was deprecated in favor of try/catch and longjmp in favor of throw.

Re:But it could be! (3, Insightful)

Late Adopter (1492849) | more than 5 years ago | (#28221705)

Nor are destructors called on longjmp.

For the love of God, man, use exceptions! That's what they're for!

Re:But it could be! (0)

TheRealMindChild (743925) | more than 5 years ago | (#28221991)

No they aren't. Exceptions are exceptional. I wouldn't say calling a deconstructor is "exceptional" by anyone's standards

Re:But it could be! (2, Insightful)

Late Adopter (1492849) | more than 5 years ago | (#28222349)

In the normal flow of execution your code goes out of scope and objects inside are destroyed. The purpose of EXCEPTIONS are so that when you have exceptional behavior, all aborted scopes are still properly cleaned up with object destruction. Longjmp doesn't do that. Hence my comment.

Re:But it could be! (1)

shutdown -p now (807394) | more than 5 years ago | (#28225165)

No they aren't. Exceptions are exceptional.

You use longjmp in "normal" situations?

Re:But it could be! (4, Informative)

mpsmps (178373) | more than 5 years ago | (#28222427)

there are no guarantee that destructors on static object will be called.

Actually, Section 3.6.3p1 of the C++ standard [open-std.org] guarantees it. (Wonder why people who can't validate technical language claims feel qualified to mod posts that make them).

Re:But it could be! (4, Funny)

siloko (1133863) | more than 5 years ago | (#28221421)

Where Java really fails is in the inability to trust the finalize method. At least in C++, the destructor of an object is guaranteed to be called as soon as the object is deleted.

Destructor!? Finalize!? Deleted!? You talking like a crazy man, have you never heard of a system REBOOT?

Re:But it could be! (1, Funny)

Anonymous Coward | more than 5 years ago | (#28221495)

windows user?

Re:But it could be! (1)

ebolaZaireRules (987875) | more than 5 years ago | (#28221461)

Hmm... I thought that even then you had to pass a VM arg to ask the GC to call finalize... ugh.
I got that far and seriously thought about switching to C++ for mini projects

Re:But it could be! (5, Informative)

Ethanol-fueled (1125189) | more than 5 years ago | (#28222017)

What you just said makes no sense. The whole point of Java is that you don't have to mess with memory management. You've just admitted that you want to invest more time and complexity in building "mini-projects" by switching to C++. Good for learning, but otherwise practically silly if you're a noob, and you've implied that you are.

As far as Java goes, ignore the command line for now. You don't need it to quickly build decent-performing applications.

Re:But it could be! (1)

ebolaZaireRules (987875) | more than 5 years ago | (#28222585)

Fine...
The jMonkeyEngine uses ODE (Open Dynamics Engine) as its rigid body physics implementation.
Whenever a new level is loaded, the old one allows all its threads to run off, and is left to rot till the garbage collector gets round to it.

The problem with this is that the memory from the physics engine is never freed, because finalize is never actually called by default.

I thought about going through it properley, but who wants to spend all day going through someone elses code with a debugger to home to spend all evening going through someone elses code with a debugger... and all for a proof of concept game.

Re:But it could be! (0)

Anonymous Coward | more than 5 years ago | (#28223931)

The problem with this is that the memory from the physics engine is never freed, because finalize is never actually called by default.

WTF?

finalize IS called by default.

Finalize is NOT called when the memory is not reclaimed.

Finalize does not "free memory". It frees OTHER SYSTEM RESOURCES that should be handled (in Java) by a finally block (hopefully Java 7 will make this a little better with ARM).

physics engine is never freed

And you know this how?
Likely it either is freed, but not handed back to the OS (this is why javas "new" is quicker than C++s(1)) so the memory is System Monitor is never reduced or YOU HAVE A REFERENCE TO IT.

YOU as in THE DEVELOPER that could be you or the developer of the API.

Not Java fucking it (its GC works fine, if it did not someone other than you would have noticed it).

1) Unless you make C++ work the same way by overriding how new & delete work.

Re:But it could be! (2, Informative)

hibiki_r (649814) | more than 5 years ago | (#28222641)

I write in Java every day, but if my code was running on anything other than an application server that takes care of most of my non-memory resources, I'd be wishing for the equivalent of a destructor every week.

It's not really about memory management though, but about resource management. Initialize your resources at object construction and release them at destruction is a very simple and elegant solution that is common on many C++ projects. In Java, we can't really do anything like that. We can't really encapsulate the resources without jumping through hoops.

Re:But it could be! (1, Insightful)

0xdeadbeef (28836) | more than 5 years ago | (#28223953)

We can't really encapsulate the resources without jumping through hoops.

Those hoops are the same hoops you're jumping through with destructors on C++. It only looks more elegant because the complexity has all been pushed into ensuring that all objects are properly destroyed when they need to be. You're doing the exact same thing using the dispose pattern in a GC'ed language, only it feels difficult because you're normally reliant on the collector, but there is a distinction between "resources" and "objects".

Re:But it could be! (1)

petermgreen (876956) | more than 5 years ago | (#28224595)

In C++ the pattern is fairly simple, every object must be cleaned up. For objects on the stack that is done automatically. For objects on the heap the programmer can either do it manually, have a single reference responsible for the lifetime of the object (auto_ptr) or use reference counting (shared_ptr).

In java the pattern is a mess, you have to check the docs for every object to see if it needs to be disposed or not and if so you have to manage that disposal manually and of course if you change an object that previously did not require diposal to require it you have to go through ALL code that uses the object and work out how to add disposal code to it.

Re:But it could be! (1)

Unoriginal_Nickname (1248894) | more than 5 years ago | (#28221613)

Give me deterministic behavior over faster GC any day.

The thing is, there really is no middle ground. You need to use a mark-and-sweep algorithm to avoid leaking cyclic references, which means you have no way of determining if an object should or should not be destroyed if it leaves scope. The good news is that a modern generational garbage collector is optimized toward collecting younger objects, so it's fairly likely that your resource objects will be collected fairly soon after you're done using them. .NET provides a modicum of determinism with a bunch of syntactic sugar for a particular interface (IDisposable). It's not RAII, but C++ doesn't have heap compaction which is far more inconvenient than having to type out a finally block every time you open a file.

Buddy heap (1)

tepples (727027) | more than 5 years ago | (#28221829)

C++ doesn't have heap compaction

There are ways around this, such as the buddy heap [wikipedia.org] and the Windows XP low-fragmentation heap [microsoft.com] , which round sizes up to a power of 2 and keep similarly-sized allocations together.

Re:Buddy heap (1)

owlstead (636356) | more than 5 years ago | (#28222133)

With C++ there is always a way to get (around) a feature. The trick is to let these tricks play nice with the rest of your pogram including the used libraries and different runtime environments.

Re:Buddy heap (1)

tepples (727027) | more than 5 years ago | (#28223455)

The trick is to let these tricks play nice with the rest of your [program] including the used libraries and different runtime environments.

That's an issue with any std::malloc replacement, but this page [stackoverflow.com] claims that Firefox manages to work around it.

Re:But it could be! (1)

SecondaryOak (1342441) | more than 5 years ago | (#28222445)

The thing is, there really is no middle ground. You need to use a mark-and-sweep algorithm to avoid leaking cyclic references, which means you have no way of determining if an object should or should not be destroyed if it leaves scope.

There are cycle-detection algorithms that do not require a full mark-and-sweep; they run a limited, local scan which can be immediately performed any time a reference is decreased to 1.

Re:But it could be! (0)

Anonymous Coward | more than 5 years ago | (#28221899)

To call a finalize on every object you create will cause you to have to have a reference to said object. This is the part of Java that I find nice is the ability to use objects with no reference like this:

  String s = new Date().toString();

There is no reference to the Date object -- all I really wanted was the String output -- it cleans up the code nicely.

Java doesn't fail (4, Informative)

beldraen (94534) | more than 5 years ago | (#28221989)

The reason why you are confused is because you're used to a compiled environment, where every call is an immediate action. A C/C++ program must be coded to (i.e. explicitly) deletes memory references. If you explicitly delete, you can also tie in other explicit behavior; therefore, it's common "duh this is how you do it" practice to tie "finalize" behavior to the object's deletion. But remember, it is your program's logic that has decided when to get rid of it. In a GC environment, deletion is no longer an explicit event--it is autonomous, automatic; therefore, it is illogical to tie anything to the deletion of the memory reference to anything other than deletion of the memory reference. There is no connection between when the object was dereferenced and when the GC chooses to clean up the reference. Generally, the only events that are tied to the finalize method are sanity checks to make sure non-Java code knows the reference is going away. Put differently: in Java, memory deallocation is not a part of the running logic of your program and so the program must create an explicit method of releasing resources in your program's logic. In other words, do what you were doing before, just don't call it finalize. That's a gripe of mine about Java: It confuses C++ users who are used to using the function finalize because Java gives finalize a specific purpose that cannot act the same way.

Re:Java doesn't fail (1)

hibiki_r (649814) | more than 5 years ago | (#28222701)

But in C++, many programs don't really deal with resource deallocation directly: That's what reference counting pointers are for. The resources get wiped the moment nothing references them anymore, and we can release both memory and connections at the exact moment they are not used anymore. In Java, just as you said, we end up doing it explicitly, doing a lot more work by hand, and risking destroying a resource that someone still has a reference to.

Sure, the code can still work, but it's a lot harder to get that done than to just let the destructors do their job when the reference counter reaches 0.

Re:Java doesn't fail (2, Insightful)

deepestblue (206649) | more than 5 years ago | (#28223215)

If you're coding in lots of explicit memory reference deletes, what you're writing is not C++ but C. A C++ codebase would use RRID and automatic memory management to obviate the need for any explicit memory management. My last C++ project at work contained zero (yes, zero) calls to delete/free() out of around 20000 lines of code and a year of development/testing.

You're making the same mistake you're accusing C++ developers of making - you're viewing C++ through Java lenses.

Re:Java doesn't fail (1)

skeeto (1138903) | more than 5 years ago | (#28223519)

This means that a resource, other than memory, can't be tied completely to an object. Anything using the object has to handle the resource manually, like basic C++ memory management, breaking the abstraction.

For example, I might want to tie, say, a database to an object. I create the object which opens/creates a database. I then use the object normally, and it makes transactions with the database as needed, but since finalize() is not reliable I have to explicitly call a close() method before I let the object fall out of scope if I want to keep the database synced up and tidy. And I can't call close() too soon or something else using the object will have a problem. If I have to do that I might as well be managing the memory too.

This has specifically annoyed me in the past and now, as I continually run into this limitation. It is on my list of "Reasons I Despise Java".

Re:But it could be! (1)

owlstead (636356) | more than 5 years ago | (#28222055)

Amazingly boring? Jeez, there is a lot of ways of doing garbage collection. You can mix GC types, have multiple levels of GC, heap sizes to tweak for these levels etc. Java has got an upper limit to the amount of memory the process uses, but I can think of other schemes that dont. Then you can do a lot of multithreading stuff, but you cannot break code anytime, because in that case the whole VM can die unexpectedly. Then you have to choose when and how long to garbage collect, if you only do so if CPU utilization is high or low. Weak references and such can also play a role etc.

If it's really boring to people they aren't trying hard enough.

Re:But it could be! (1)

SecondaryOak (1342441) | more than 5 years ago | (#28222155)

I disagree about the "boring" part. I took a university course on garbage collection (and a bit more, but that was the main topic) and it was absolutely fascinating. It was filled with a lot of interesting challenges - like how to handle multithreaded systems, how to avoid dirtying the cache, how to write incremental garbage collectors to prevent pauses, etc.

Re:But it could be! (0)

Anonymous Coward | more than 5 years ago | (#28222283)

What's boring to one person is of great interest to another. There are piles of interesting problems being tackled in developing garbage collectors - it's one of the areas in computer science that's actively evolving, and it's receptive to new ideas or approaches.

Also - much of the Java language/libraries were designed with the hope that desctructors would go out of style. I'm not saying desctructors don't have their uses - a number of core classes have finalizers, proving their use. You can always write your code so that they aren't required, though. I have yet to encounter a problem where I've needed one - when I've come close, it's worked out just fine to perform clean-up with a weak reference queue.

GC and the desctructor (1)

testman123 (1111753) | more than 5 years ago | (#28222305)

A destructor is useless with a GC.

The finalize method was only introduced in some situation where you need to make memory cleaning easier & faster.

If you are developing a regular program, you will never need to ever think on finalize. Using WeakReferences, Handles (look NIO for instance), you don't even need to know what is finalize() and what is the subilities it has. In the same way as the .wait() or .notify() !

This is the problem with developper comming from C/C++, they have been so focussed on memory management problems that they can not understand it has been solved (with a CPU & memory cost) thru GC usage.

Having automatic memory handling, does not mean you are freed from error. One famous problem is the loitering references, a reference you did not take notice to kept a bit longer than required in your code, but unfortunatly this reference has reference to lots of objects that have also reference...etc. The problem is getting worse if the place you are keeping tis reference is under a static zone or in a daemon thread.

The known solution to this is :
  1- never keep a cache of objects that are external to your domain unless you know what you are doing or unless you are using a weak reference to point each object and performing the appropriate presence test on them.
  2- never store a reference to your domain in a foreign domain (worst example of this is swing client properties) unlessyou know what you are doing or unless you are using a weak reference to point each object and performing the appropriate presence test on them
  3- never use string interning (cf. .intern()) unless you truly understand it and can control the memory usage impact you will have on the VM on the long run.

If you follow those simple advices, you will never have to think about .finalize() anymore :)

Allright, here is my question : we know that GC are now well known techniques and have reached to a suitable level of maturity. Why is there no GC directly written in the microprocessor ? I mean, these are basic feature that a processor could control and perform better than anybody else. All languages could benefit this by replacing memory allocation techniques !

This would be a huge step forward IMHO.

Re:But it could be! (0)

Anonymous Coward | more than 5 years ago | (#28222571)

Not really sure if you really need destructor calls, the only area i can see where it would make sense even in garbage collected environments is ressource cleanup like file closing, but on the other hand relying on destructors for file closing is an antipattern in itself!
In c++ it just makes sense because you dont have garbage collection so introducing object counters etc... via destructors is heavens sent in those surroundings!

So use real-time Java (3, Informative)

shis-ka-bob (595298) | more than 5 years ago | (#28222965)

If you want to control garbage collection, you should use the real time version of Java. Go to youtube and view Java RTSJ on Wall Street pt1. Here are folks that greatly value deterministic behavior, and they are choosing Java over C++. Why? Because it is predictable and you get access to the tools, developers and tools of the Java World.

Re:So use real-time Java (-1, Troll)

LordKazan (558383) | more than 5 years ago | (#28223845)

did you just attempt to claim c++ isn't predictable?

and then expect us to listen to you on anything else?

they're choosing java because it's the current "enterprisey" "solution"

Re:So use real-time Java (1)

tkinnun0 (756022) | more than 5 years ago | (#28224423)

Ever heard of the terms undefined and unspecified behaviour? Well, I guess one could argue about the predictability of unpretictability...

Re:So use real-time Java (1)

LordKazan (558383) | more than 5 years ago | (#28224819)

all that "UB" means is that the standard doesn't care. and it always describes something that you're not supposed to do.

No problem with predictability there.

Re:But it could be! (0)

Anonymous Coward | more than 5 years ago | (#28223305)

Destructors/finalizers/etc are nearly never used in the course of design in languages that are built upon a framework that use a GC. Best practices have long accepted this fact; you close connections, free resources in the course of your application logic, rather than is being a passive act. Managing the tedium of your own garbage collection for most applications is a proven waste of time, this is why we arrived at GC. Clearly there will always be exceptions :)

Re:But it could be! (1)

tkinnun0 (756022) | more than 5 years ago | (#28224677)

Exactly, and it's because that neat little abstraction called close() includes "tell them my regards and then bid them adieu" and "oh, you're still here?" and everything in between. How could one automatic clean-up abstraction deal with all that nuance without butchering something or other.

Re:But it could be! (1)

againjj (1132651) | more than 5 years ago | (#28225217)

Garbage collection is an amazingly boring field of computer science.

And so is , unless it isn't. Any time some one says, "X is boring," or, "X is interesting," that really means, "X is boring TO ME," or, "X is interesting TO ME." "Boring" or "interesting" is opinion. Personally, I find GC rather interesting, in particular the latest advances in real-time GC. I did compiler/programming languages work for my M.S., and I believe that most people would think that it is boring as well, but it is not to me.

It's all about tracking references

There is a lot more than that.

Well.... (4, Insightful)

samriel (1456543) | more than 5 years ago | (#28221201)

I think this means that, if you use the new GC in a production setting and it clobbers some mission-critical piece of data, they would really like you to have some support contract with them, rather than never using G1 or Java again. It is 'early release' after all.

Re:Well.... (0, Funny)

Anonymous Coward | more than 5 years ago | (#28221671)

Well, that missing "/" in the italics tab clobbered your post, Sam.

Re:Well.... (1)

Rosco P. Coltrane (209368) | more than 5 years ago | (#28221713)

Contracts for garbage collection eh? I knew Sun was in cahoots with the mafia. Just ask these guys [reuters.com] if they don't wish they had stuck with the old Java...

pork (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28221219)

ham

Where did the wild pigs go? They stole my umbrella and pooped on my flowers.

Not quietly (5, Informative)

RPoet (20693) | more than 5 years ago | (#28221221)

Sun didn't "quietly edit" the release notes; they announced it [sun.com] publicly and appologized for having been unclear (which seems like a bit dishonest, but not quiet).

Re:Not quietly (3, Insightful)

Joehonkie (665142) | more than 5 years ago | (#28221285)

What you said here. People were so buy foaming at the mouth that they never bothered to read the actual article or the thousands of posts that spelled out pretty clearly how and why the slashdot story got it wrong.

Re:Not quietly (4, Funny)

causality (777677) | more than 5 years ago | (#28221715)

What you said here. People were so buy foaming at the mouth that they never bothered to read the actual article or the thousands of posts that spelled out pretty clearly how and why the slashdot story got it wrong.

Never seen that before. No, not ever.

It's funny when you can cut+paste your comment and drop it into multiple discussions without having to modify it. It is truly one-size-fits-all.

"Stop. Look. Listen, learn, read, think .. SHUT THE FUCK UP!" - Bill Hicks

Re:Not quietly (1)

harryandthehenderson (1559721) | more than 5 years ago | (#28221731)

People were so buy foaming at the mouth that they never bothered to read the actual article

But but but! Oracle is eviiiiiiiiiiiil! Who cares what the truth was? Did you know that Oracle was eviiiiiiiiiiiiiiiiiiiiiiiil!

Re:Not quietly (0)

Anonymous Coward | more than 5 years ago | (#28222073)

Ah, but they did read the article. The exact quote from the old release notes is:

Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased.

Regardless of what the license says, that seems pretty clear to me: if you want to use G1 commercially, you gotta pay.

Just because it wasn't true, doesn't mean that Sun didn't say that it was.

Re:Not quietly (0)

Anonymous Coward | more than 5 years ago | (#28222257)

Zealot! Slashdot is never wrong! Recant!

Re:Not quietly (0)

Anonymous Coward | more than 5 years ago | (#28223575)

Did the text go through Oracle first so they could throw some sticks into the mud?

Slashdot editors don't read slashdot? (5, Informative)

argent (18001) | more than 5 years ago | (#28221253)

This is not a change, it was clear in the previous thread that the article was completely misinterpreted. The Slashdot summary made no sense at all once it was pointed out that G1 was GPL+Classpath.

Re:Slashdot editors don't read slashdot? (1)

harryandthehenderson (1559721) | more than 5 years ago | (#28221487)

Well when did ScuttleMonkey ever actually read, or even comprehend, the articles he posts?

Re:Slashdot editors don't read slashdot? (0)

Anonymous Coward | more than 5 years ago | (#28221597)

Since when did ANYONE on Slashdot ever actually read, or even comprehend, the articles they posted?

Re:Slashdot editors don't read slashdot? (1)

harryandthehenderson (1559721) | more than 5 years ago | (#28221633)

True. I seems like poor English grammar skills and reading comprehension are requirements for becoming a Slashdot editor.

Re:Slashdot editors don't read slashdot? (1)

Reality Master 201 (578873) | more than 5 years ago | (#28221903)

Or a reader. I wonder how this correlation relates to causation.

Re:Slashdot editors don't read slashdot? (1)

nystire (871449) | more than 5 years ago | (#28222119)

One must be a reader before one becomes an editor...

Re:Slashdot editors don't read slashdot? (1)

slack_justyb (862874) | more than 5 years ago | (#28222459)

Ah yes, but Slashdot suspends all logic. Therefore, one must be an editor, before one becomes a reader, before one becomes an editor, before one becomes a reader... aka, randomly hit a submit button (no one cares just hit any submit button!)

Great fun!

Probablly just a misunderstanding (4, Insightful)

petermgreen (876956) | more than 5 years ago | (#28221275)

I would guess a developer said something vauge like "don't use this in production without a support contract" and it got misunderstood by the person writing the release notes. If they really wanted to forbid it I'd expect them to be competant enough to do that in the license.

No Way! (5, Funny)

Anonymous Coward | more than 5 years ago | (#28221313)

A kdawson article that totally blew something out of proportion? What a shock!

Re:No Way! (3, Informative)

harryandthehenderson (1559721) | more than 5 years ago | (#28221465)

Actually the original article was posted by ScuttleMonkey, but both are masters at spreading misleading, FUD-filled articles.

Re:No Way! (0)

Anonymous Coward | more than 5 years ago | (#28224545)

An Anonymous Coward post that totally blamed the wrong incompetent Slashdot editor? What a shock!

Was this ever an issue? (4, Insightful)

Lemming Mark (849014) | more than 5 years ago | (#28221341)

Argh, so I'm turning into the kind of person who comments without reading *either* article in question but ...

Last time this came up, plenty of people pointed out that the G1 garbage collector was available to anyone, Open Source but that it was in development and you weren't recommended to use it in production without a support contract. A number of people even pointed out the settings that anybody could change to enable the experimental G1 garbage collector on their own system.

Perhaps this is case of adjusting their wording to make it easier for Slashdot to not report incorrectly ;-)

Stop spreading FUD (5, Insightful)

harryandthehenderson (1559721) | more than 5 years ago | (#28221595)

So does this mean it was all one huge typo? Or was Oracle/Sun tentatively testing the waters to see the community's reaction? In either case it's nice to see Java's back on the right path."

No, it means that the original article was a misleading pile of FUD since the G1 garbage collector was released GPL + Classpath exception from the beginning. It's amusing that after being pointed out that the original submission was misleading and wrong that instead of this being a retraction that this article still tries to implicitly claim that Sun or Oracle did something wrong.

Re:Stop spreading FUD (0)

Anonymous Coward | more than 5 years ago | (#28222039)

please mod this up.

which czar does our dear leader have running slashdot??

Popular Java Myths (4, Informative)

javacowboy (222023) | more than 5 years ago | (#28221665)

1) Java is slow
2) Java is not yet open source (or only parts of it are or isn't "really" open source)
3) Java is not available in any Linux distro's package manager
4) Java does not meet the needs of the enterprise
5) Nobody uses Java anymore
6) "Java is a heavyweight ball and chain"
7) Sun is charging people to use the new G1 garbage collector.

Java has some weaknesses and disadvantages, but the above are not among them.

Re:Popular Java Myths (3, Insightful)

owlstead (636356) | more than 5 years ago | (#28222491)

1) Java is slow.

I'm generally a Java advocate, but you have to take into accounts when Java *is* slow. This is mostly where Java has to get down to the nitty gritty of the bare metal. Examples are cryptography (lots and lots of low level operations on bytes, 32 and 64 bit words) and processor based instructions. In those cases it makes sense to use a well defined C library (avoiding C++ if possible) and interface with that. These are also the places where it makes sense to really optimize the hell out of an application or library.

But for general business logic this arguement is indeed long gone. I do believe that my Java applications are normally faster than their C++ counterparts for the simple reason that I've got more time to design my classes well. Even if it's slower then it's offset by the much lower maintainance cost. And it's way faster than most specialized languages. Then again, specialized languages can make sense if they are delivering lower maintainance cost. Lets just say that not choosing Java because is it slower *per se* is absolutely wrong.

Re:Popular Java Myths (1)

slack_justyb (862874) | more than 5 years ago | (#28222499)

You forgot

8) Java for web pages = JavaScript (or vice versa)

I'm sure there is more.

Re:Popular Java Myths (1)

petermgreen (876956) | more than 5 years ago | (#28222507)

1) Java is slow
Semi-true, java is what you get when you take a language that is slow by design and optimise the hell out of it. Overall perforamnce is reasonable but not brilliant (shootout.alioth.debian.org places it at arround 1.5 to 2 times slower than C). Predictability of performance can be a problem though because instanciating a new class can mess with the inheritance tree and hence the performance of seemingly unrelated code.

2) Java is not yet open source (or only parts of it are or isn't "really" open source)
The truth or falseness of this depends on what you consider to be part of java. There is an open-source version and it can pass the platform compatibility tests but it's not entirely the same code as the binary releases and IIRC it lacks implementations of some optional parts of the platform. Also only a limited selection of CPU and OS ports were released. Also last I checked the source for the official java plugin was missing (there are third party ones though I dunno what thier compatibility is like currently).

3) Java is not available in any Linux distro's package manager
It is now but this is a fairly recent change. It only made it into debian lenny by the skin of it's teeth.

6) "Java is a heavyweight ball and chain"
Semi-true, java is a huge platform that makes it difficult to interact with code written in other languages though there is now a third party library (jna) to make it easier.

7) Sun is charging people to use the new G1 garbage collector.
Well that is what thier release notes originaly said though I don't think it was backed up by any statements in a license.

One huge typo? (1)

toby (759) | more than 5 years ago | (#28221679)

Well, the keys are right next to each other...

By the way, the research paper describing G1 is here [sun.com] .

Little Early to Bring Up Oracle (1)

Kagato (116051) | more than 5 years ago | (#28222185)

Until the deal closes Oracle has nothing to do with Sun's Day to Day operations. Once Oracle takes over take bets on what happens to MySql and Glassfish. Until then, they don't have squat to do with it.

Re:Little Early to Bring Up Oracle (1)

Zarf (5735) | more than 5 years ago | (#28222279)

The fact that Larry was on stage bidding farewell to the senior staff of Sun at JavaOne doesn't help the rumor mill one bit.

garbage collect itself? (0)

Anonymous Coward | more than 5 years ago | (#28222365)

if the GC is working correctly, it should garbage collect the entire Java language, and flush it down the toilet.

It's still too slow

It's still not deterministic

It's still lacking IEEE-754 floating point compliance

It's still lacking STANDARD implementations of many COMMON functions

It's still NOWHERE NEAR write once, run anywhere, it's more like write once, test against 3 difference versions of the JRE, and hope users have the right CLASSPATH set.

I still worry... (1)

tekiegreg (674773) | more than 5 years ago | (#28222551)

If Oracle is about to manage Java the way they manage their database product (basically letting Microsoft get ahead with SQL Server in many respects), I think Java's in trouble with .NET rumbling straight at 'em...

Re:I still worry... (1)

tthomas48 (180798) | more than 5 years ago | (#28222795)

Uh. Sure. This will be a problem when Microsoft makes .Net run well on Linux. Until then they'll just be that really obnoxious loud truck rumbling in the next lane over.

I have no idea what you mean by SQL Server being ahead of Oracle, but SQL Server also only runs on Microsoft OSes and is thus only useful for people who run Microsoft OSes.

It's not because you aren't paranoid that java.... (1)

flibuste (523578) | more than 5 years ago | (#28223183)

Or was Oracle/Sun tentatively testing the waters to see the community's reaction?

It'd be great if my fellow slashdotters stop giving in the PROFIT conspiration theory, just one time.

Just wondering is there a GPU like GC?. (0)

Anonymous Coward | more than 5 years ago | (#28223529)

Is there anything like a hardware based GC?. Imagine all object life cycle and reference change events are fed in to GPU like dedicated hardware and the hardware determines which object can be dumped. Would it be worth?. If a GPU can process billions of whatever, why not GC. It should be there already somewhere, why it is not in wide use?.

Not Oracle/Sun Yet (4, Informative)

fm6 (162816) | more than 5 years ago | (#28223653)

Or was Oracle/Sun tentatively testing the waters to see the community's reaction?

It's a little early to talk about Sun as a part of Oracle. It's probable that the acquisition will clear regulatory approval, but until it does, Oracle can't play anything resembling a decision-making role in something like this.

I work at Sun, and right now our contacts with Oracle are actually more circumscribed than they'd normally be.

Re:Not Oracle/Sun Yet (1)

Red Flayer (890720) | more than 5 years ago | (#28224149)

It's a little early to talk about Sun as a part of Oracle. It's probable that the acquisition will clear regulatory approval, but until it does, Oracle can't play anything resembling a decision-making role in something like this.

That's a laugh. At the operational level, Oracle will not interfere much until the acquisition is approved.

But at the strategic level? You can bet your bottom dollar that Sun isn't blowing its nose without checking with Oracle to see if it's OK first.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?