Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Java Programming IT Technology

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!"
This discussion has been archived. No new comments can be posted.

Have a Nice Steaming Cup of Java 5

Comments Filter:
  • Java is to C as ... (Score:4, Interesting)

    by SamSeaborn ( 724276 ) on Thursday September 30, 2004 @08:52AM (#10393182)
    Java is as far above C as C is above Assembly.

    Microsoft was right to be afraid, developing in Java is a delight.

    Sam

  • by Offwhite98 ( 101400 ) on Thursday September 30, 2004 @08:52AM (#10393187) Homepage
    After they took all that time to rewrite it with the latest API they claim they can closely track Sun releases. This will be the first big thing since then, so it will be a test of Apple to get it out quickly.
  • J2EE --> 1.3.1 still (Score:5, Interesting)

    by tezza ( 539307 ) on Thursday September 30, 2004 @08:54AM (#10393194)
    If you develop apps targeted at Websphere 4, say, they're still 1.3.1 spec.

    I look longingly at typed collections to save yet another ClassCastException on anonymous iterators. *sigh* oh well, maybe 6 years from now...

  • by OhHellWithIt ( 756826 ) * on Thursday September 30, 2004 @08:54AM (#10393199) Journal
    Scott McNealy got my dander up in the quotes in this Government Computer News article [gcn.com].
  • by mirko ( 198274 ) on Thursday September 30, 2004 @08:54AM (#10393200) Journal
    The operators, a^Hthe feature that I just love in C++ is stil not present in Java, ok, it got faster, but still not as fast as C++ too.
    I guess this will finally come but when ?
  • by B5_geek ( 638928 ) on Thursday September 30, 2004 @08:57AM (#10393210)
    I have found that most (2 of the 3) Java Apps that I used have horrible memory leak issues. I can't let the computer run for more then 3 days or all kinds of funkyness begins (winxp).

    I have been using Sun's JVM. I realise that the memory leaks are very likely the fault of the apps themselves, but it seems that the whole JMV is kinda flakey too.

    Hopefully this new release works better.
  • by smari ( 257143 ) <spm.vlug@eyjar@is> on Thursday September 30, 2004 @08:58AM (#10393223) Homepage
    I personally have never liked Java, but it's hard to dislike... it's a nice syntax, and makes for nice clean code.

    What bugs me about Java is the virtual machine. Native code please! The "compile once, run anywhere" idea is good enough, but Perl is definately a much better candidate for such things, wheras it is open source and therefore portable to _anywhere_ without the folks at Sun having to give their approval.
  • useful or bloat? (Score:5, Interesting)

    by N3wsByt3 ( 758224 ) on Thursday September 30, 2004 @09:01AM (#10393233) Journal
    Well, some may call the 1.5 as being increasingly bloatware, but, why in some aspects this may be true, I think all by all there are considerable improvements over the former releases, especially 1.4.2.

    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.
  • by tmasssey ( 546878 ) on Thursday September 30, 2004 @09:01AM (#10393237) Homepage Journal
    I've been disappointed with IBM's response to Java lately. The last version easily downloaded for Windows is 1.3. The only way I was able to get Java 1.4 for Windows was to download the MQ Series client (like 200MB big!) and pull the JDK out of that...

    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...

  • by Sanity ( 1431 ) on Thursday September 30, 2004 @09:03AM (#10393255) Homepage Journal
    Apparently it is planned for release with Tiger, the next major release of OSX. I don't know whether it will be available prior to the release of Tiger, if not, it is likely to prevent most developers from coding in it (what is the point in coding in Java if it won't work on the #2 desktop OS?).
  • by MemoryDragon ( 544441 ) on Thursday September 30, 2004 @09:06AM (#10393281)
    Actually no, it is an app problem. Sun has introduced weak references way back in 1.3 to cope with that problem. And I have to admit, I never had any of these problems since 1.3
    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.
  • by ancice ( 817863 ) on Thursday September 30, 2004 @09:06AM (#10393290)
    Nice that Java VM is now faster; it's one of the major drawbacks of java on the desktop. But how does this compare with the new and shiny Mono? Mono with its distributed system, and if it still beats Java, then java is in for a tough fight.
  • by Anonymous Coward on Thursday September 30, 2004 @09:10AM (#10393321)
    It won't take that long. the reason they say they can now track it closely, is that the current impl isn't the nasty hack that was the mrj, but just a simple port of the sun sources, which have been working on freebsd for ages. os9 required complete rewrites/reimplementations of huge chunks of the java api.
  • by Cederic ( 9623 ) on Thursday September 30, 2004 @09:18AM (#10393393) Journal

    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
  • Is it C# yet? (Score:2, Interesting)

    by LibertineR ( 591918 ) on Thursday September 30, 2004 @09:20AM (#10393411)
    Metadata attributes? Generics support?

    In Java you will not see any performance improvement; the reason is well explained by Anders Hejlsberg (lead C# architect) in http://www.artima.com/intv/generics2.html [artima.com] :
    "For example, with Java generics, you don't actually get any of the execution efficiency that I talked about, because when you compile a generic class in Java, the compiler takes away the type parameter and substitutes Object everywhere. So the compiled image for List<T> is like a List where you use the type Object everywhere. Of course, if you now try to make a List<int>, you get boxing of all the ints. So there's a bunch of overhead there. Furthermore, to keep the VM happy, the compiler actually has to insert all of the type casts you didn't write. If it's a List of Object and you're trying to treat those Objects as Customers, at some point the Objects must be cast to Customers to keep the verifier happy. And really all they're doing in their implementation is automatically inserting those type casts for you. So you get the syntactic sugar, or some of it at least, but you don't get any of the execution efficiency. So that's issue number one I have with Java's solution."

    You can argue with Anders, but then, you would be wrong.

  • by jg21 ( 677801 ) * on Thursday September 30, 2004 @09:25AM (#10393469)
    In an interview [sys-con.com] given just last night, the spec lead for 5.0 is asked what in his view the coolest new feature of the language is. Calvin Austin replies: If I just restrict myself to the language it would be metadata (JSR 175). We've only scratched the surface of its potential. For the platform, it's a bytecode insertion for profiling (JSR 163).
  • by Anonymous Coward on Thursday September 30, 2004 @09:25AM (#10393470)
    Babelfish says RMS has not been involved in the accident contrary to previous rumors.
  • Re:Passe... (Score:4, Interesting)

    by spellraiser ( 764337 ) on Thursday September 30, 2004 @09:31AM (#10393530) Journal
    Yes, it's not C#, but it is getting closer and closer to being C/C++ (or something very very close). For instance, Java 5 borrows features heavily from C. Just take a look at some of the new features:

    - 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:1, Interesting)

    by Anonymous Coward on Thursday September 30, 2004 @09:39AM (#10393613)
    (usage of this looks quite similar to the #define method)
    #define isn't a method, its a preprocessor directive.

    Anyway, adding features like this from C doesn't necessarily make a language better. It just makes it more like C. But given that the aim of a language is to by widely used, and you can't swing a USB cable without hitting a C programmer, thats not necessarily a bad thing either.
  • by mattdm ( 1931 ) on Thursday September 30, 2004 @09:41AM (#10393646) Homepage

    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:

    B. License to Distribute Software. Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the Software README file, including, but not limited to the Java Technology Restrictions of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and

    (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....

    i: I don't want to distribute it for the "sole purpose of running [my] Programs". I want to distribute it so people can run other people's programs, including possibly their own.

    ii: uh, well, actually, my "Programs" don't add any functionality to Java, let alone "significant and primary".

    iii: oops, I include gcc, which has a Java compiler. And I'm definitely not going to drop that.

    iv: ahh, now this one I can agree with -- fine keep your copyright notices, etc.

    v: my distribution as a whole is under the GPL. I'd have to run this by our lawyers, but this looks like it'd conflict by requring additional restrictions (even if I could get special dispensation to deal with the other issues).

    vi: I don't really have the resources to defend and indemnify Sun "from and", even if I wanted to, thanks.

    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.

  • Speed and resources (Score:0, Interesting)

    by Anonymous Coward on Thursday September 30, 2004 @09:49AM (#10393746)
    I work for a company where our entire service is dependant on java applications. As a systems admin at this company, I can safely say that java is a hideous resource hog of ridiculous levels, and it's bitch slow compared to things written in real languages, on even the fastest machines.

    I will say however, that it is far more reliable now, than it was say 2 years ago. For this I am thankful, as the callout phone rings less frequently.

  • by DevolvingSpud ( 774770 ) on Thursday September 30, 2004 @09:52AM (#10393779)
    How about Borland JBuilder? That's a big, powerful IDE, and I'd consider it a successful commercial product. Also, from the games side, Puzzle Pirates [puzzlepirates.com] is a Java game, and good chunks of Chrome [chromethegame.com] are Java. Oh yeah, plus about a billion cellphone applications.
  • Rapid learning (Score:5, Interesting)

    by GeekDork ( 194851 ) on Thursday September 30, 2004 @09:54AM (#10393820)

    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.

  • by DaveLatham ( 88263 ) on Thursday September 30, 2004 @09:56AM (#10393845)
    Does anyone know if there are any changes between this and the release candidate, and what they are?
  • by julesh ( 229690 ) on Thursday September 30, 2004 @10:05AM (#10393942)
    Carrying on down this path much farther, you become able to argue that C is just syntactic sugar for assembly language, and therefore assembly language is just as good.

    Face it. Syntax matters.
  • Re:Eclipse 3.1 betas (Score:4, Interesting)

    by Mechanik ( 104328 ) on Thursday September 30, 2004 @10:07AM (#10393964) Homepage
    Now we just need to be able to build Eclipse itself using Java 1.5. I really really want to use 1.5 in my Eclipse plugins. I want real container classes dammit! :-P

    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
  • by Anonymous Coward on Thursday September 30, 2004 @10:31AM (#10394291)
    (what is the point in coding in Java if it won't work on the #2 desktop OS)

    It doesn't work on Linux?
  • Re:Swing on OpenGL (Score:2, Interesting)

    by Anonymous Coward on Thursday September 30, 2004 @10:52AM (#10394559)
    This didn't work for me with beta2 or RC on windows or linux on two different machines both with NVIDIA cards and binary drivers. The OpenGL pipeline was enabled (see output with -Dsun.java2d.opengl=True, note capital T), but it ran very very slow and with corrupted images.

    Just tested -- doesn't work on the release version of 1.5 either.
  • Re:Passe... (Score:5, Interesting)

    by mmusson ( 753678 ) on Thursday September 30, 2004 @11:01AM (#10394704)

    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.

  • by Anonymous Coward on Thursday September 30, 2004 @11:03AM (#10394738)
    The new loop is pretty awful. Why? Because it *cannot* be fast. It has set slowness in stone. It's guaranteed.

    The problem here is that iterators are slow. Very slow. Because they require two un-inlinable method calls per element in the iteration. Iterating over an ArrayList is EIGHT TIMES SLOWER than scanning over an Object array and casting to the right class, and SIXTEEN TIMES SLOWER than scanning over a properly typed array.

    Iterators can't be inlined because the compiler doesn't have the concrete class -- it just knows it's an iterator. If you cast the iterator into its concrete class and set it to a concrete-class-typed variable, you could get java to inline the methods, and Iterators would be at least somewhat fast.

    Unfortunately, the new loop construct makes this impossible. Thus, it is *guaranteeed* to be sixteen times slower than how you could do it elsewhere.

    Crap, that's bad.
  • Re:I love the hate (Score:3, Interesting)

    by renoX ( 11677 ) on Thursday September 30, 2004 @11:18AM (#10394980)
    > You can't hate any language as much as some people hate Java until it's really reached critical mass.

    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.

  • by figa ( 25712 ) on Thursday September 30, 2004 @11:29AM (#10395158) Journal
    I ran into a fabulous memory leak just last week thanks to Sun. I wrote a client that was accepting messages and persisting them using ObjectOutputStream [sun.com]. I persisted about 40,000 HashMaps, and next thing, my client was using 200M. I wasn't building any lists of the messages, so I was stumped, and I broke out the profiler.

    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.

  • by rreyelts ( 470154 ) on Thursday September 30, 2004 @11:36AM (#10395276) Homepage
    It has been known for a long time (over a year), that Java programs compiled for 1.5 will not run on a 1.4 VM. However, you can use tools like Retroweaver [sf.net] to get 1.4 compatibility. It rewrites the bytecode of your version 1.5 class files into the 1.4 VM format.
  • by Anonymous Coward on Thursday September 30, 2004 @11:36AM (#10395281)
    I'm veering off-topic here, but it's weird to me that a clone of Microsoft's clone of Java [go-mono.org] is easier to include in a Linux distribution than Java itself, from a licensing standpoint. I never compared the two in that light. Hmph.
  • by sbrown123 ( 229895 ) on Thursday September 30, 2004 @01:00PM (#10396121) Homepage
    Object orientation is a terribly inefficient way to program.

    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);
  • by Cederic ( 9623 ) on Thursday September 30, 2004 @01:27PM (#10396529) Journal

    >> Java generics don't provide any performance benefit

    On the contrary, they provide the ability to write code faster, to understand code faster and to maintain code more easily, leading to fewer bugs, and thus less testing, and thus faster deployment.

    That's a hell of a cost saving - more than enough to buy a slightly faster CPU, if you're really concerned about runtime performance.

    >> Autoboxing: this feature removes clarity from the language.

    I must have misunderstood this one. I thought it was simple auto-translation from primitives to their object equivalents (e.g. Integer to int and vice versa). Personally I have no clarity issues with

    List listOfNumbers = new List();
    listOfNumbers.add(5);
    System.out.println ("Number added = " + listOfNumbers.get(0));

    Sure, that's a shite example, but it's late at night. There's autoboxing going on in that add(5) call; I don't think it's hurt clarity at all.

    >> Enums

    That's certainly a potential issue when dealing with object references using an Enum pattern; I haven't tried that scenario in 1.5 so not whether that'll be a problem. Of course, if you rely on .equals() instead of == (as you generally should for all class types) then I'd expect Enums loaded from different class loaders to still be .equals() equal and thus your problem wont arise. Good spot though, I'll have a play and experiment with that one.

    >> Annotations: I really don't see the point of this.

    It's an exceedingly powerful addition to the language, albeit one I'm far from certain I'm happy about.

    See the Apache Beehive project for an indication of what can be achieved with these things. (e.g. a one line annotation to turn a class into a web service - that's a lot of code you didn't have to write).

    Personally I think they add a lot of complexity to the language, and that does (as your post's main thrust seems to suggest) make the language weaker - not because it's less capable, but because it's harder to understand and to write. Note that I'm not lazy, I'm not looking for a language that does everything for me and doesn't make me think; I'm looking for a language that lets me think about the logic I'm writing, rather than the language mechanics being used to express that logic.

    >> New for: This simply makes the code harder to read.

    I'm going to challenge that. Yes, maybe harder for read the first time(s) you come across it, but after that, every bit as simple as the current 'for'. If anything, potentially simpler..

    >> Static imports and variable length parameter lists: I think these are well done.

    At risk of sounding argumentative, I'm even going to disagree with your only positive comment on the changes.

    Static imports add no value that I can perceive. They are there purely to entice users of other languages. I like having use of statically declared values qualified by a classname, it makes the code more readable and adds a little context.

    So some of the changes I welcome, others I am more uncertain about, and a couple I'll dissuade people from using (to prevent misuse and aid code readability - where I am, maintainable code counts for a lot). I wouldn't however agree that "They fucked up Java".

    ~Cederic

  • by E_elven ( 600520 ) on Thursday September 30, 2004 @01:45PM (#10396766) Journal
  • Re:I love the hate (Score:3, Interesting)

    by Featureless ( 599963 ) on Thursday September 30, 2004 @01:55PM (#10396896) Journal
    I wrote the original post you seem to quote

    Well, I left you a message to tell you I quoted it, so hopefully it's not a surprise.

    5-6 seconds of startup for a few boxes of interactive input is not really acceptable.

    Thus, using Java for a few boxes of interactive input is also unacceptable.

    The startup times are slow. That's one of the real problems I was talking about - one, in fact, lamented from within Sun. For VMs that have this problem, this limits their usefulness a bit.

    Hasn't stopped the language's implacable advance, though. Let's see, do you know why? "Because 90% of the time, nobody gives a shit."

    I did not miss your attempt at humor. I am saying saying it was a bad attempt - misleading, not really illustrative.

    one-size-fits-all applied to extremes allways results in the effects I described. ... Merely a user of apps written in your favourite cure-all language.

    Did you read what I wrote? I will repeat it, with emphasis:

    "...things that make any really big language a target: 1) people start using it for everything, including things its not suited for..."

    Do you really need to continue to manufacture the straw man that someone thinks Java is the right language for everything, in order to have a point?

    if you go nuts and have hundreds of objetcs, events and containers all over the place, you are bound to end up with huge overhead.

    Congratulations, sir. You are a computer science genius.

    Java from what my (cursory I admit) glance at the language/libraries takes this to just such extremes.

    You have just saved me the trouble of pointing out that you are apparently ignorant about the system. The balance of abstraction and efficiency in the java architecture is actually surprisingly good, and I would say better than most other comprable systems.

    But of course, you seem to like writing Gameboy games, or device drivers, or something. Yes, keep jamming the square peg in the round hole. Damn that naughty peg. It never fits. It's the peg's fault.

    The "Just Too Late" was just a pun on the hype JIT is endowed with. The memory requirement (if you had read the thread where the original post was made) was confirmed by just about anybody including those who advocate Java.

    You segue from JIT to memory too quickly for someone really familiar with VM or OS internals. Something tells me you're not the kind of guy who looks at how big the resident set is when he checks memory usage.

    The JIT works very well. The garbage collector works very well. For overall memory usage, Java has room to improve.

    Yet strangely, the language is so popular. Why? "Because 90% of the time, nobody gives a shit." We've already GOT RAM. what we needed was a clean, well-organized high-level language, and the trade was just what the market wanted.

    Better yet, this is not necessarily a problem with Java as much as with VM implementation, as the wide usage of Java in consumer and embedded devices conveniently underscores, it is not necessary to have high memory overhead; this is the result of the major VM vendors trading memory for speed in products aimed at the workstation/server market. As time goes by the RAM overhead can be improved (by Sun or by the market picking up the slack), if the market wants it.

    a 10-15 meg per JRE + 10-50 (memory managment seems to suck badly for the apps we use) per instance of an application

    So, how many simulatneous VM instances do you typically run at once, comrade?

    I dont care who broke whose toys.

    When selecting a platform, language, or implementation strategy, I can see how you would consequently run into some trouble.

    If I am forced to let people download and install JRE's du-jeur for each e-commerce craplet out there, this is far worse then any other "client side" app.

    Golly,
  • Re:STUPID MODS (Score:3, Interesting)

    by pediddle ( 592795 ) <pediddle+slashdot@NoSPam.pediddle.net> on Thursday September 30, 2004 @02:45PM (#10397459) Homepage
    So are the vast majority of internet games [yahoo.com]. I don't go a day without seeing somebody play poker, pool, or fantasy football online.
  • Re:Passe... (Score:3, Interesting)

    by rreyelts ( 470154 ) on Thursday September 30, 2004 @03:19PM (#10397799) Homepage
    No, autoboxing suffers an entirely new set of problems. For example, let's take a container, which is the most commom usage case of generics.
    1. You will be forced to box and unbox upon every single access to that container. Boxing can be quite expensive, compared to simple operations, because it will usually involve a memory allocation - which can suffer even more under multiprocessor boxes due to heap contention.
    2. Your container will use a much larger amount of memory compared to an array of primitives. Compare an int[] to a List<Integer>. The int[] will cost you 4*N bytes. The List<Integer> will cost you 16*N bytes - 4*N for the Object[], 8*N for the two-word object header for each Integer, and 4*N for the actual int value stored in each Integer.

    For systems like mine, that store 100 million objects in memory, a 4X memory increase is hugely unacceptable, and the access penalty is also unacceptable. My situation is not uncommon, and it is the reason why libraries like fastutil [unimi.it] exist and are so popular.

    I think .NET is mostly a rip-off of the JVM with very little innovation, but they seem to have a much better approach to primitives, with JIT type-specialization [microsoft.com]

  • Re:I love the hate (Score:3, Interesting)

    by IgnoramusMaximus ( 692000 ) on Thursday September 30, 2004 @04:12PM (#10398332)
    In other words, it's possible to write shitty code in either Java or another Object Oriented language

    Quite true although it is not humanly possible to have more hype, hot air and hubris in any other language other then Java, C# being second close contender. Why if one were to listen to what we are being told, one cant possibly write bad code in Java for the language is divine and one's hand is guided with certainty by the fairies of object-oriented-pointerless-bliss.

  • Re:I love the hate (Score:4, Interesting)

    by IgnoramusMaximus ( 692000 ) on Thursday September 30, 2004 @05:53PM (#10399311)
    30 shitty applications. That's the sample you've built this thesis on? That's it?

    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

  • by vegetasaiyajin ( 701824 ) on Thursday September 30, 2004 @06:22PM (#10399533)
    As far as experience tells me, short code is almost always more readable than long code (except for abusive use of regexps and such stuff). Java 1.5 new features are great because they make your code shorter, hence more clear.

    Dismissing something as syntactic sugar is just silly. Java generics may be not perfect, but they make code shorter, therefore clearer.

    it is not that they are not perfect. They are completely broken. I am not against adding generics to Java. But, I prefer Java without generics than with the crappy implementation they came up with.
    If they had implemented generics properly I would not be complaining. I would be very happy instead.
    First of all, they should have supported primitives in generics. This could have eliminated the need for autoboxing.
    They instead went for a crappy implementation of generics and then another crappy workaround (autoboxing) for not having made a good generics implementation.
    And you are wrong saying that language constructs that are shorter are automatically clearer.
    By that logic, Perl would be one of the clearest languages of all.


    Maybe you enjoy having to manually cast each time you use a container like ArrayList, or to manually write your own class ListOfT each time you want to use a list of elements of T type. I dont. Generics make my life easier, Im glad they included them.

    You belive they make your life easier.
    When you have to deal with the errors of the implementation you are going to see how easier it is.


    I fail to see how autoboxing can make your code any significally harder to read. Its like saying method overloading should be banned because it makes code harder to read as it makes it impossible to determine what a method does only by its name.

    I am not a big fan of method overloading, but I certainly would have prefered method overloading instead of the pile of broken crap they came up with.
    As to how clear Autoboxing is, please explain the clarity of this:
    Integer a = 2;
    Integer b = 2;
    boolean flag;
    flag = a>=b; //true
    flag = a<=b; //true
    flag = a==b; //false
    I fail to see how that is clear. Why is it clear that == should not be used for comparing objects, but >= and
    In general, no one is forcing you to use any of this new features. If you find people using them, it is probably because they are USEFUL.

    If I find people using them it will be because:
    a) they are ignorant and don't understand how broken Java generics and autoboxing is.
    b) They have no choice because they have invested a lot in Java and now the standard library is rewritten using templates as will several other tools too (probably for one of the two reasons).


    I hate the fact that some people refuse to accept something can makes code clear if it doesnt stick to their own dogmas on programming styles.

    I hate the fact that some ignorant people just fail to see how broken something is and criticize knowledgable people (and I am not talking about me, but many experts whose opinion I share) because they point out the flaws of something they believe is good.
  • by fupeg ( 653970 ) on Thursday September 30, 2004 @06:58PM (#10399790)
    The whole point was not "how does Java solve this super tough problem". The point was that it's not a hard problem and that anybody who knew anything about how garbage collection works would not make such a comment. Of course Slashdot is all about not knowing anything about a subject but making claims about it anyways. Mark and sweep is not the actual algorithm used by JVMs, it is just a simple algorithm that any programmer (and I use that term loosely) should know about from a data structures course. There are actually numerous gc algorithms used by JVMs, in fact you can specify different types of algorithms for the JVM to use based on the type of application and the type of hardware running the application. But do yourself a favor and try to learn the basics first.
  • by Coward the Anonymous ( 584745 ) on Thursday September 30, 2004 @09:43PM (#10400764)
    " Yeah, because device drivers and operating systems are being written in Java"

    http://jnode.sourceforge.net/portal/ [sourceforge.net]
    "The goal is to get an simple to use and install Java operating system..." ;-)

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Working...