Have a Nice Steaming Cup of Java 5 859
wap writes "The language/VM/religion that everyone loves to hate is now serving another cup: Java 1.5 is ready for download. The new features of 1.5 have been discussed here before. I, for one, welcome our new virtual machine overlord. I have been using the release candidate, and startup times are noticeably faster, as is overall performance, and the new features like typesafe collections and static imports are great to have. Let the Java flames begin!"
Thanks to our supporters (Score:5, Funny)
Oh, yeah, and ridiculously large settlement payments by Microsoft."
Re:Thanks to our supporters (Score:5, Insightful)
your cut is the fact you can use it for free!
A. Coward
Re:Thanks to our supporters (Score:4, Funny)
I wait! (Score:5, Insightful)
Re:I wait! -- you mean... (Score:5, Funny)
Re:I wait! (Score:3, Funny)
Finally! (Score:4, Informative)
Eclipse 3.1 betas (Score:5, Informative)
Re:Eclipse 3.1 betas (Score:4, Interesting)
Currently you probably could build Eclipse using 1.5, but the Eclipse release engineering folks are still building using 1.4 (or at least, they were as of a month or so ago, and I haven't seen any mailing list traffic to the contrary). There won't be any official builds of Eclipse done with 1.5 for a while yet I think.
Mechanik
Java is to C as ... (Score:4, Interesting)
Microsoft was right to be afraid, developing in Java is a delight.
Sam
Re:Java is to C as ... (Score:3, Insightful)
I was about to mod this as Funny, but then I realized that you weren't making a joke.
Back in the day, the tagline was "C -- all the speed of assembly, with all the programming ease of assembly."
--
Free gmail invites [slashdot.org]
Re:Java is to C as ... (Score:3, Insightful)
Re:Java is to C as ... (Score:4, Funny)
Too bad you can only drink "sweet sweet chocolate" in a dark, virus infested alley, while coffee can be enjoyed by everyone, everywhere.
Re:Java is to C as ... (Score:3, Funny)
Re:Java is to C as ... (Score:5, Interesting)
OOP advantage is best seen in large projects. Particullary collaborations. I've worked on large codebase non-OO projects before and know the headaches.
Also, what about compile times and the fact that Java actually doesn't work on all interfaces?
Dunno. What interfaces are you talking about?
Compile times? Java's pretty speedy compiling. Than again, I dont have a 286. Will say this though: Make is a hell of a lot quicker than Ant. Ofcourse you could always use Make for building java though.
(And as a side note, I don't like the fact that you have to type four lines of code to do what C++ could do with a simple cin >> var;
in Java would be:
System.in.read(var);
How long will the MacOS X release take? (Score:5, Interesting)
Re:How long will the MacOS X release take? (Score:4, Interesting)
Re:How long will the MacOS X release take? (Score:4, Informative)
Not really. CodeGuide, www.omnicore.com, thats an IDE, has a MAc release since years. That allows using Java 1.5 features in coding. And as you can create byte code compatible with JDK 1.4 released software will run on a Mac as well. Tehre are minor issues however e.g. new methods in java.lang.String wich work fine in the IDE (becase the classpath is different) but not in standalone mode. Nevertheless, I'm coding on a Mac, not necessaryly for a Mac, thats why I use java with generics and the later Java 1.5 betas since over 2 years now. (And since about 14 month on a Mac).
I would expect that Eclispe and other major IDE vendors have a Mac version bundled with JDK 1.5 runtime libraries as well.
angel'o'sphere
Re:How long will the MacOS X release take? (Score:5, Informative)
Perhaps because it will work on the #1..n server OSes?
Re:How long will the MacOS X release take? (Score:4, Informative)
But by your post, you had probably already guessed that. At least it's probably less than four years, like it was before Mac folks got JDK 1.2...
Re:How long will the MacOS X release take? (Score:5, Funny)
Passe... (Score:5, Funny)
Man, that's not really fair (Score:3, Funny)
...
Come to think of it, this entire situation is sort of starting to sound like, um, something else...
Re:Man, that's not really fair (Score:3, Insightful)
Re:Passe... (Score:4, Interesting)
- Generic Types (AKA templates)
- Enumerated Types
- Static Import (usage of this looks quite similar to the #define method)
- Formatted Output / Input (printf/scanf style)
- Varargs
I like this trend. These, among other changes in version 5, are all steps towards reducing the awkwardness in the Java syntax that many people complain about. Java is a young, evolving language that still has a lot of potential.
It is a bit funny, though, that this evolution takes the form of borrowing stuff from an ancient language. Maybe C just got things right in the first place, huh?
/me puts on a flameproof suit
Re:Passe... (Score:3, Informative)
Generics != C++ templates (Score:5, Insightful)
Generics in Java have a smaller scope, when compared to C++ templates. The objective in Java is to provide a type-safety mechanism for containers. In C++, it is much more than that. Unfortunately, it is this extra ability in C++ that makes for some really complex code. Not sure if this has already been mentioned in this story, but it has been theorized that C++ templates are themselves turing complete (though I havent seen a proof to that effect).
I'm a bit puzzled by all the generics nay-sayers. I have tried out the feature, and they augment the language. I have yet to see a downside to this feature in Java (unless one counts the inability of the compiler to fully utilize the additional type-safety in compiler error messages). What is all the flap about?
Re:Passe... (Score:5, Interesting)
I was actually looking forward to templates in Java but was disappointed once I saw the implementation of generics.
Every cast operation in Java is expensive because the VM invokes security code to verify that the cast is legal. Java generics don't allow you to avoid the implicit cast so you still get the performance hit. Generics only make the code look cleaner.
Template meta-programming is also a very important part of the modern C++ libraries and is also something that generics cannot do.
Re:Passe... (Score:5, Informative)
My apologies for the horrible look of the code samples. Slashdot won't let me use nice, short lines, as it results in lines which are too short. Gah! Apparently I need ~40 characters per line (average) to get past the @#$% filter... This has to be the most annoying filter I've ever come across; I've spent more time getting past the filter than responding to your question!
Iterators are similar to java.util.Iterator. C# iterators are compiler support for implementing the System.Collections.IEnumerator interface. For example, in Java you'd write:
C# iterators make this much easier:
C# iterators are particularly useful when implementing your own collection objects. Google for them; they're very powerful.
Anonymous Methods are methods without a name, just like Java anonymous classes are classes without a name. Same basic idea, fewer braces. They also act as full closures; while Java requires that all stack variables referenced from an anonymous class be final, C# doesn't require this.
The above example is bad, but you can let your imagination run wild. This is very useful for event handlers.
Partial Types
allow you to split a single class definition across multiple files. This is useful to prevent > 50 KB source files (yech!), and makes it easier to have part of a class machine generated (by a GUI builder) and part hand-written. Some people hate it, others are ambivalent, but it can be handy:
Nullable types are primarily useful for database support in the .NET type system. DB types can be "nullable" -- not present. For reference types, this is easy -- use null. For .NET value types, this isn't possible, as value types can't be null. The solution is to introduce a generic class System.Nullable<T>, which can wrap value types such as int.
The C# compiler adds syntactic sugar to this, to simplify usage:
Nullable types are more special purpose, but are useful for those who need them.
Ignore the rest of this: it's just garbage to get past Slashdot's wonderful "too few characters per line" problem: lk jfjdlkajdsfl;kja sdfl;kja fjklsafjd l;kj lasjd lkjds fl;kja sdflkajsd lkj afs lk jfjdlkajdsfl;kja sdfl;kja fjklsafjd l;kj lasjd lkjds fl;kja sdflkajsd lkj afs lk jfjdlkajdsfl;kja sdfl;kja the quick brown fox jumps over the lazy dog l;kajdsfl;kj;lkj l;kjasdilfj l;kjoiewqruq[op 0-9314u75 lkfjx ;lkajdsfmopiac un0p3u5n1-0329u kl 0a9u 3214o5ilj hello out there in tv land! q 09
Re:Passe... (Score:5, Informative)
For example
Re:Passe... (Score:4, Funny)
Ah, yes. The old "CAT-5-o'-nine-tails."
J2EE --> 1.3.1 still (Score:5, Interesting)
I look longingly at typed collections to save yet another ClassCastException on anonymous iterators. *sigh* oh well, maybe 6 years from now...
Re:J2EE -- 1.3.1 still (Score:4, Interesting)
I wonder if IBM will have a 1.5 JDK? For a company that is putting a lot of juice behind Java, it seems odd that they don't make the JDK available to others...
Re:J2EE -- 1.3.1 still (Score:3, Informative)
Re:J2EE -- 1.3.1 still (Score:3, Informative)
Re:J2EE -- 1.3.1 still (Score:4, Informative)
However, your ClassCastExceptions will only get bumped to compile time in JDK 1.5, true. But I must admit that in eight years of Java programming, I've never had this particular problem where it didn't take more than a few seconds to find the source of the bug.
I really just want the metadata stuff (which was obviously ripped off from C#, but it's a great idea). That, and EJB 3.0, which gets rid of the stupid deployment descriptors.
Well for us Apple elitist bastards (Score:4, Funny)
I just got my copy... (Score:5, Funny)
Release notes (Score:5, Informative)
Stealing my tongue (Score:5, Funny)
I, for one, welcome our new virtual machine overlord.
Dude you know you are not supposed to say these things in the story itself.
useful or bloat? (Score:5, Interesting)
JVM 1.4.2 (at least some sub-versions) were riddled with bugs, which, for instance, become apparent when people use systems that rely on it in a special way, as with Freenet. It comes as no surprise, that there were numerous reports of some errors on OSX and BSD, as well as on linux, when running JVM 1.4.2. For some time, we had to say "If you experience any difficulties, please try/revert to JVM 1.4.1 or 1.5.x and see if that solves the problem."
It is crazy to recommend reverting, but the main devls of java were unwilling to remedy the bugs in 1.4.2, claiming it was a Freenet-problem, while our devls said it was a JVM problem. Though it must be said some within freenet claim their is little to no problem with it (probably windows-users, or maybe some sub-versions that worked on specific linux-distributions). Anyway, my advice has always been, and will be (certainly in the light of the stable 1.5 release), to NOT use the 1.4.2, especially when using OSX or another 'nix based OS.
And also; be sure to get the JRE, and not the full SDK, unless you plan to develop Java software.
The new for loop and type safe collections rock (Score:5, Informative)
It would be nice though if Sun would make Groovy or Jython a standard part of their java distribution. That would definitely make it competitive with
Re:The new for loop and type safe collections rock (Score:5, Insightful)
Re:The new for loop and type safe collections rock (Score:4, Interesting)
Face it. Syntax matters.
Sugar != Bad (Score:3, Insightful)
Actually, except for the standard assumption that sytactic sugar [wikipedia.org] be an extension of a core language (and not a completely separate language), it's pretty much true that C is syntactic sugar for assembly language. But syntactic sugar is neither good nor bad in-and-of-itself. If a given instance makes programming easier to do and easier
Re:The new for loop and type safe collections rock (Score:4, Insightful)
The new for loop most certainly is syntactic sugar. It's taking something we could do before and shortening it into a new construct.
However, a lot of folks use 'syntactic sugar' as a derisive term. It's not. It saves programmer time. Generally the times that it's bad are when it's (a) hiding what's really happening to a degree that introduces bugs, or (b) misguided, like SQL's attempts at being English-like.
The language wars never ceases to amaze me (Score:4, Insightful)
I try to stay pragmatic about the programming languages that I use. For some jobs, Java would be my last choice, and for some it seems a natural fit. When writing hardware near code, or platform dependant stuff on driver level, nobody in their right mind would attempt to use Java. For high level rapid prototyping, Java is a often a quick and easy way of getting things done.
Re:The language wars never ceases to amaze me (Score:3, Insightful)
If you compare language to language, say Java to C, C# or even Ruby and Python, it is easy to see why Java is "slow" and "bloated". But Java is to be compared to something like
Java is a platform. Java provides on-the-fly class loading and verification including digital signing of the code, very fine-grained security model (you can create your own sandbox with whatever security rules you
hmm. but how does this compare with Mono (Score:3, Interesting)
Re:hmm. but how does this compare with Mono (Score:3, Informative)
Despite the having a slower VM, the
But back to Mono it will probably never be able to catchup speedwise with
Re:hmm. but how does this compare with Mono (Score:3, Insightful)
Write once, run anywhere (Score:3, Insightful)
Re:Write once, run anywhere (Score:3, Interesting)
Rather than mod you troll, here's a simple answer.
>> Does anyone think it will ever take?
What makes you think it hasn't? A single example: What percentage of Apache Foundation products are written in and/or for Java. Note that Apache Foundation products are used extensively in Enterprise software development, deployment and systems.
~cederic
Re:Write once, run anywhere (Score:3, Insightful)
Rather than mod you troll, here's a simple answer.
I honestly wasn't trying to troll. If you walk into a computer store and look at all the off-the shelf consumer-level software products, they're all for Windows. I was hoping that Java would have changed this so that you can buy one of these off-the shelf products and run it on any platform. I know that it has gained acceptance at the enterprise level, I was actually referring to the consumer level.
Bytecode Compatibility (Score:5, Insightful)
Whilst code that uses the new language features must obviously be compiled with the v1.5 JSDK, this means that it must also be run on the v1.5 JRE.
This may inhibit the use of Java 5 by projects that want their programs to run on a v1.4 JRE.
- Brian.
Re:Bytecode Compatibility (Score:5, Informative)
Re:Bytecode Compatibility (Score:5, Informative)
But what about your classpath, does it reference the 1.5 JRE? E.g. if the 1.5 java.lang.String gets loaded by an old JVM you might get that errro as well.
angel'o'sphere
Re:Bytecode Compatibility (Score:3, Insightful)
I would hope that 1.2, 1.3 and 1.4 bytecode would run in the 1.5 JRE. I think it's ambitious to expect 1.5 bytecode to run in a pre-1.5 JRE - the language has new features that such JREs don't know about or support.
While you could obviously write code that interprets 1.5 bytecode so that it will run on a 1.4 JRE, and make it possible to automagically create that code at compile-time, including it by default in the compiled 1.5 code would be wasteful as it's not required to run in a 1.5 environment.
So yes
Re:Bytecode Compatibility (Score:5, Informative)
The bytecode format is still identical. The version number on the file was incremented because classes that depend on assertions could break badly if used on a JVM that doesn't implement them (which is actually a feature of a few classes in java.lang, not a bytecode interpreter feature). Use the '-target' commands recommended by the other posters whenever producing code that doesn't rely on one of the new features.
Re:Bytecode Compatibility (Score:3, Interesting)
Metadata is the coolest new feature in 5.0 (Score:5, Interesting)
Swing on OpenGL (Score:5, Informative)
This does indeed work too, I have played around with it and graphically intensive Swing applications really fly with OpenGL activated (given that your graphics card and drivers are sufficiently bug-free and modern). Read about it here [sun.com]
And yes, it does work under Linux, and Windows and Solaris (and most likely will under OS X, though that is up to Apple to implement).
Even without OpenGL acceleration the Swing responsiveness improvements are very impressive, coupled with the much better both default theme and theme mimicking in 1.5 I'd say it is time to retire the Swing troll.
Re:Swing on OpenGL (Score:3, Insightful)
Any idea if there's a way to turn this on or off programatically?
Having this on the command line is ok, but if someone is using Mesa3d(software openGL on Linux) instead of hardware acceleration, it will be slower than the default rendering path of X11.
Here's [cox.net] a screenshot of my JTurtle [cox.net] application running on accelerated openGL with jdk1.5 and using the new look and feel.
I love the hate (Score:5, Insightful)
There are two things that make any really big language a target: 1) people start using it for everything, including things its not suited for. 2) junior folks without a lot of compiler or cross-language experiences will cut their teeth on Java, and at that point in one's career it is sometimes considered cool to blame a bad application's flaws on the language it's written in.
Java has plenty of problems. There are brilliant essays written on it; some of them by Sun engineers. But the complaint linked to in story was so bad by comparison, however, I doin't feel offtopic in addressing some points it raised:
there are a thousand "super-efficient"
No.
it takes 12 objects instantiated in 4 containers to flip a bit in a byte
Oh, I see. You're flipping bytes.
there is the substitution of native performance of compiled code to code compiled "Just Too Late" combined with exceptional memory usage that entails
The VM is more work. Strangely, you will have trouble finding benchmarks that make other comparable high-level languages look way faster than Java on the same _non-user-facing_ application.
As always, code in C, assembler, or another specialized language if you really need to.
The speed thing is well-addressed elsewhere. Enough said for now.
we get the garbage collector which is scientifically fine-tuned to run just when user is expected to interact with the application in most time sensitive manner
People love to bitch about client-side Java. It's as if all the flaws they're used to from other client side systems are fine, because they're used to them, and every foible of Java is worth agonizing over as if it were the worst thing in the world.
I dunno what else to say, but I wrote an enormous graphic-intensive video game in it and it runs fine. And what I did is nothing; somebody cloned the QIII engine to the point where it plays actual Q3A maps (with multiplayer) at respectable framerates.
Once again, someone shows me a shitty client app written by a team of 30 22 year olds in Thailand and claim it's proof that Java sucks. Congratulations.
multiple, insideously incompatible with each other, versions of the so-called "universal" VM
Yes, leaving aside the fact that Microsoft deliberately broke VM compatibility. Not just in one or two big ways. In a lot of little ways. As in on purpose. Great example. Very honest.
There is a giant test suite. Gets better all the time. Reputable VM's pass it. Most of all, though, I just don't run into the cross-VM problem in the first place unless I'm doing 1.1 development for browsers, see above...
We actually abandoned DB2 8.x release because noone could deal with the havoc the DB2 admin tools were causing with various other retarded banking related Java apps.
There we go. The truth outs. You overpaid for a shitty product. Congratulations. You can do that in C or Fortran, too.
Blame the language, though. Don't blame yourselves for picking a bad app.
Oh well, time to have me shot on sight.
Have a nice day.
Rapid learning (Score:5, Interesting)
As much as I might hate Java, I repeatedly have to throw this one thing into the fray: I had exactly zero former experience with network programming, and still, I was able to produce a basic telnet-like application in under 30 minutes, using only the Java API doc and some logical thinking. And I only had a very brief introduction into the language. Transferring this to C (although the basic structure is exactly the same with BSD and Java sockets) took me about a week, with all those damn low-level error conditions.
Exactly (Score:3, Insightful)
Re:Rapid learning (Score:5, Insightful)
Joking aside, it kills me to see the amount of research and due-diligence that goes into debunking a Microsoft-sponsored benchmark, but when it comes to Java most everyone starts spouting nonsense. People will remember their experiences from 8 years ago, or a bad app, etc. and immediately conclude that Java must suck for every conceivable application.
Java is a tool - no more, no less. Use it where you think it is useful and leave on the shelf if you don't think it will help solve your current problem. Most mature developers know when and where a tool should be applied.
Re:I love the hate (Score:3, Interesting)
Untrue, there is no need to wait to hate Java, I tried Java in 98-99 and hated it, its libraries were full of bugs (Swing, the GC was leaky on 1.1.8) and you spent your time working around the bugs.
Re:I love the hate (Score:3, Insightful)
there are a thousand "super-efficient" .jar libraries required by a "Hello World" app
No.
Well it certainly feels that way when you try to load those apps. They all have excruciating startup times. Perheaps I am wrong and instead they check the integrity of my bank account or weather in China for my convenience. I dont really care, but 5-6 seconds
Re:I love the hate (Score:4, Interesting)
I will keep repeating ad nauseum that those are the only applications that count to me and many businesses that use them. That is a 100% of a sample of a Java apps that are shitty. Either all of those were written by poeple have no clue what they are doing (unlike all of those wonderful mythical apps always deployed somewhere else and written by enlightened geniuses) or the Java snake oil is just that.
and I am starting to wonder how much experience you have in general, because what I'm conspicuously not hearing is X and Y and Z systems are way better for A and B and C. Just vague generalities about HTML forms and (I think?) coding in C? Or do you perhaps favor VBScript?
Since you are getting more incredibly fanatical and blind by the minute, let me spell it out for you as clear as I can:
For e-commerce, OS/browser agnostic plain HTML on the browser is the only sane way to do anything because it does not rely on any client capablities other then ability to render HTML. No deployment issues, no maintanance costs. Java (and ActiveX and C# and similarly retarded ideas) is a way to create deployment issues and thus support costs and thus employment for countless Java tweaker monkeys. Something dear to your heart no doubt.
For applications that must run on thick-clients (I sure hope due to CPU usage because any other reason in a corporation is plain retarded) one can use native code just fine because: vast majority if C or C++ or any other language programs need only to support very few platforms in their entire life span and the effort to optimize that program for these platforms is well paid for by removal of integration and thus support issues. But such need is extremely rare because vast majority never leave a single platform. A Windows Java app will never run as well as a native Windows app neither will unix Java app run as well as a native unix app. This is not even up for discussion. The most convoluted of JITs and what nots are still overhead over native code and I will not even entertain any moronic discussion on that topic no more that I will entertain discussions of how you can make 2 and 2 equal 7.
I regret to inform you that you are full of shit.
I regret to inform you that you are just a priest of yet another silly language who has no clue who pays his bills. VB apps are everywhere in business, far more so then Java ones. These numbers are representing current jobs, corresponding to a peak in a cycle of a fad, VB waning hard (previous fad), Java peaking (current fad) and C# just coming up. I am fully expecting to have this very same retarded conversation with a C# priest, in, oh about 4 years time.
You sound confused. Are you saying it's easier or cheaper to write native applications? That natives are more secure? Are you happy with all your current native applications?
No it is you who is utterly confused, something about a theory whereby the Earth is flat and supported by Java beans. To spell it out for you again (I will resist an urge to use large letters): Native apps are easier to write (many decades of experience and tools), run better (many decades of OS design and integration of apps with the OS), cheaper to write and support because they use proven framework and tools, they integrate well with the user environment, have better performance (even the not so well written ones) and the so called "write once, deploy everywhere" is not only unnecessary but is more accurately described as "write once, debug and crash everywhere". Are they more secure? Depends what kind. The "no client side, java-less, HTML only e-commerce"? Most certainly. The locally deployed, locally networking native apps? They are not any more vulnerable then the OS itself. Are we clear now, Your Beanness?
nobody sees the world ending but you, all those students and professors, all those magazines and newswpapers and Fortune 500 compan
Re:I love the hate (Score:3, Informative)
Here [slashdot.org] it is.
Ad seen on Monster today (Score:5, Funny)
Okay, I'll Bite (a.k.a. "A Java Flame") (Score:5, Interesting)
I work on a minor, highly targetted Linux distribution. I'd love to include Java, and I actually get a lot of requests for it. But, here's an excerpt from the license agreement you'll find if you look to download the software:
(Yes, it really does just end abruptly without finishing the sentence. That trailing "and" there doesn't lead into the next section; it's just not done. Obviously I'm the only one who bothers to read these things -- *including* the people at Sun. Anyway....)
My wish to give the software to my users fails almost every test....
And frankly, that's why I wish people would stop writing things in Java. It's a pain to deal with. I want to make everything as slick, integrated, and as easy as possible for my end users. Sun makes that impossible for Java applications. If you want your code to be easily integrated and made available to users like mine -- and really, that's users of any Linux distro targetted more broadly than the super-geek sector -- please don't use Java. If you must, at least design it to work with gcj instead of Sun's virtual machine.
Unless Sun changes the license terms, their Java can never fill the "write once, run anywhere" goal -- but cleanly written source in an open language can.
Performance improved? Not in my experience... (Score:3, Informative)
Test I did: Run 'ant -lib lib checkstyle java' on XINS [sf.net] 0.207)
Preparation command:Timed command:I did 3 tests in a row for each Java version. I added the 'user' and 'sys' times and the averaged then. Results on my Gentoo Linux system with 2.6 kernel:
SLOW (Score:3, Insightful)
Since 1.0 there have been three major speed holdbacks preventing me and many others from adopting java:
1) array access too slow due to boundary checking (no, their optimizer doesn't work for my cases, and this is a problem a lot of scientists/performance hungry people have).
#1 has some good solutions on 64-bit platforms developed at the university of georgia, but sun won't include them, nor will they enable a flag on the jvm to turn of bounds checks. GCJ lets you do it, but can't compile everything I need yet.
2) casting raw memory to objects requires a copy. Java needs a structured object without a header to overcome this, such as the struct proposal, which is in the top 25 rfe's yet has no comment from sun.
#2 has a well understood solution that sun is apparently too lazy to even consider implementing.
3) No way to do fast 2d/3d rendered graphics. Too many call overheads & copies.
Sun needs to ditch AWT/Swing, and probably needs to open source java to overcome this. They've proven their inability to keep up a reasonable mapping to modern featuresets.
I'm probably going to have to give up and learn c# since I'd like a more modern language with good tools, but java just doesn't have the speed.
Re: (Score:3, Informative)
Re:Stability/memory leaks (Score:5, Insightful)
Java should never have memory leaks...
All the memory managment should be done by the VM as far as I know...
unless there is some advanced stuff i'm just not aware of?
Not memory leaks as such, but "memory leaks" for all practical purposes. How? Well, if you forget to nullify references to objects you no longer use, the garbage collector obviously cannot reclaim that memory..
Re:Stability/memory leaks (Score:3)
As far as I'm aware, I don't think your entire app is supposed to be in main(). I normally don't ever nullify references, but my code is modular enough, (i.e. not all in main()) that objects go out of scope when they are no longer needed. This is one of the most ridiculous examples of a straw man argument I have seen.
Re:Stability/memory leaks (Score:4, Insightful)
That's the whole point of the garbage collector:
a = new Class1();
a = new Class2();
The Class1() object will be picked up by the garbage collector and deleted (assuming the garbage collector is not broken).
a = new Class1();
a = null;
a = new Class2();
This defeats the purpose of having a garbage collector.
Re:Stability/memory leaks (Score:4, Informative)
However, you are quite correct. It can be quite difficult at times to ensure that all objects are correctly cleaned up after usage. As soon as you introduce items such as HashMaps, etc, you run into potential for these problems.
We once had this issue when we embedded the mozilla javascript interpreter in our app. The problem was that you have to create a scope object, with all sorts of predefined classes and functions and so forth. This was expensive, so we pooled them. Unfortunately this left a memory leak, as objects declared in scope by the javascript itself would not tidy up at the end of processing.
Indeed it turns out the library has parent scopes, so we could create a new child scope cheaply each time, but the point remains.
Re:Stability/memory leaks (Score:5, Interesting)
I was surprised to find that the ObjectOutputStream has a static HandleTable inside it that creates an entry for each HashMap that I put through, and it keeps a reference to each HashMap. I searched around, and this is a common problem [utwente.nl] that is not mentioned at all in the javadocs. You're supposed to reset [sun.com] the ObjectOutputStream periodically to free up the HandleTable. I had assumed that reset was like InputStream's reset [sun.com] and never would have guessed that it had to do with Object caching in the stream.
Re:Stability/memory leaks (Score:4, Informative)
Yes, Java's GC would notice that nothing is referring to them and remove the objects. This unlike a simple reference counting gc such as python's which would not notice this. Java's GC can even relocate memory on the fly to minimize page misses and avoid memory fragmentation.
Re:Stability/memory leaks (Score:4, Informative)
Yes, Java's GC would notice that nothing is referring to them and remove the objects. This unlike a simple reference counting gc such as python's which would not notice this.
Your information about Python is about four years [python.org] out of date.
Re:Stability/memory leaks (Score:3, Informative)
Yes, Java's GC would notice that nothing is referring to them and remove the objects. This unlike a simple reference counting gc such as python's which would not notice this. Java's GC can even relocate memory on the fly to minimize page misses and avoid memory fragmentation.
Python actually uses a generational garbage collection system that can break cycles to reclaim unused objects. It also performs certain optimizations to avoid unnecessary memory allocations and deallocations.
In Python, reference c
Re:Stability/memory leaks (Score:5, Insightful)
Java's garbage collection sort of creates a general laziness among some coders who don't clean up because they don't have to.
This is a missconception of yours. In Java, you CAN'T clean up. In C++ you say , in Java you just say Probably I should correct my sentence above: freeing memory IS CLEANING UP, nothing else, so all Java programmers clean up automatically.
All it takes is one pointer *ahem* reference to some object that contanis a reference to another, that contains an array... If you've got a few hashes and arrays in the way, it may be difficult to tell exactly where memory is being used, thus memory leaks.
Well, for a GC that is not difficult to tell at all. Not harder as for a human
In C++ somewhere somehow one had called delete. So at the point where in Java a hughe amount of memeory is referenced, and probably never used again, you have a dangling pointer in C++.
but would what happen if two objects referenced each other but nothing else referenced them. Would gc know to follow the links between the two and see that nothing in the main app is using them?
Of course, thats the point about garbage collection
If you have a memory leak in java then it comes from things like that:If you do somewhere something like this you will run into an OutOfMemoryException sooner or later
It is really no difference if one "forgetts" a delete in C++ somewhere or one forgets a x = null; in Java somewhere, but the Java program won't crash indeterministic, thats a difference.
angel'o'sphere
Re:Stability/memory leaks (Score:5, Interesting)
But it also could be that your program simply needs a tad more ram.
Following, check out the -Xmx and -Xms parameters of your application startup file and add more ram (java fetches 32MB in without any params and fills it up before it starts the GC for the first time) That might help.
But never count memory leaks out, they are very rare, but can happen if somebody has tangling references, pretty much the only case where the Garbage Collector can do basically nothing.
The VM itself is not flakey, I have a few servers running here, with an uptime of a year already.
It's out there! (Score:3, Informative)
I gave it a whirl about a year ago and it was fine, fine for the relatively simple stuff I experimented with.
J.
mod parent down (Score:5, Insightful)
No, I don't think you should write ls or grep in Java. However, I'd say that you also shouldn't be writing an invoice processing system in C or C ++.
Re:Nice language... bad interface (Score:3, Insightful)
Java is not open source, hence I do not go around compiling it anywhere.. I just wait and hope that Mr. Star gives a yellow light on the project.
No you can't run it anywhere you like! (Score:4, Informative)
Justin.
Re:Still no operators... (Score:4, Informative)
> I guess this will finally come but when ?
Errr...
Java 1.4 was comparable in speed to C++ [idiom.com] (except obviously for Trig which got a huge overhaul in 1.4 and slowed down some)
It really depends how you write you code... Sloppy C++ code can be slow too..
Re:Still no operators... (Score:3, Insightful)
I take it from this comment that you haven't actually tried java. You can "explorate" to your hearts content, and there are many ways of doing the same thing (some obviously better than others)
> mostly because of the plethora of APIs (WebLogic, etc.) that corporations force you to use over it...
Now this comment just has me bamboozled... You mean that Weblogic holds sway over you and force you to code in one way ov
Re:5 or 1.5? (Score:5, Insightful)
Fairies have wings, not tails.
I agree though, the naming of Java is consistently confusing. Should I upgrade from Java 2.. err.. J2SE.. err.. Java 1.3.1_08 to Java 5 or to Java 1.5 or indeed Java 1.5.0. Oh, and is J2EE 1.4 compatible with this new one?
It could be much simpler..
~Cederic
Re:Is it C# yet? (Score:4, Insightful)
Priority #1 for Sun was not to break the bytecode format. Priority #2 was to ease the life of programmers
The only thing which really will make a difference on code generation level will be the meta data, this one will make life easier for the implementors and for the users of servers. Soap instantly comes to my mind with the C# like @webmethod metadata. No more post and precompilers for doing that stuff, yiehaa.
Hjelfsberg is a smart guy, although I dont share his views on unmanaged exceptions, he is dead right with his comment on this.
Re:Is it C# yet? (Score:3, Insightful)
A C# fan accusing Java of copying?
Excellent. Go Sun, Go!
Re:Well, since you people ask this.... (Score:3, Insightful)
http://www.joelonsoftware.com/articles/APIWar.h t ml
If you like C#, VB and
Re:Dear Sun (Score:5, Informative)
1) go to java.com [java.com]
2) click the big "get it now" button
3) download the EXE
Now quit trolling.
Re:Dear Sun (Score:3, Funny)
Um... I've been a Java developer for about 5 years, and I've never seen that website. Now, can someone please tell me why Sun has put fscking RINGTONES on their Java site!?
Not really. (Score:5, Insightful)
While I think "write-once, run-anywhere" is a bit of a misnomer, it does actually live up to the hype, imho.
You can't really appreciate it however, until you've spent weeks porting C code between platforms, and a few hours porting similar Java code.
I've had headaches porting perl too (though I must admit its much better now). Things these days are much better for people *trying* to develop cross-platform applications in Java and a number of other languages and APIs, but when it gets sprung on you as a requirement late in the game (latter revisions, new customers, etc) porting a Java app is a godsend.
There's alot of valid reasons to hate any language (I've studied 22 languages and in their own way, I think they all suck), but that particular reason doesn't apply to Java.
Re:STUPID MODS (Score:5, Informative)
Thought not.