Slashdot Mirror

← Back to Stories (view on slashdot.org)

Java 5 RC Available, Gold Targeted for this Month

Posted by CowboyNeal on from the test-driving dept.

Trevor Leach writes "Sun's Java 5 download page is now serving up J2SE 5.0 RC. There are loads of productivity enhancements in this release, code named 'Tiger,' including generics, enums, autoboxing of primitive types, and metadata. Additionally, the Java Developer's Journal qoutes Sun's Graham Hamilton, chief technologist of Java Software, as specifying September 30 as Tiger's target release date."

65 comments

  1. Are people still using java? by kiddygrinder · · Score: 4, Funny

    Why would you want to use java? .Net is NEW! it's got MS on it! If you go by memory footprint it's way bigger and therefore better!

    --
    This is a joke. I am joking. Joke joke joke.
    1. Re:Are people still using java? by aled · · Score: 1

      Because Java is tried and trusty. Or perhaps portability. I use it for both. Unless you think Mono is a portable .Net -which is not- then .Net has no portability at all. And I didn't like some previous things in languages/platforms from MS, but some tools were good.

      --

      "I think this line is mostly filler"
  2. autoboxing ? by BigBadDude · · Score: 4, Interesting



    why is autoboxing so darn important to some people??

    i will probably never use it because if i want a hash-table of integers or a binary-tree of doubles, i will write it myself with the native types. it is faster, and eats less memory.

    the whole idea of hiding complexity by converting int to Integer and vice versa automatically is kinda scareing.

    not to mention the waste of memory for creating those stupid wrapper objects...

    1. Re:autoboxing ? by rmull · · Score: 4, Interesting

      Ways to measure time:
      1) execution time
      2) development time

      1 is usually less important than 2. Really. If it saves me one round trip to the compiler, I'll take it. The merits of the boxes themselves aside, this is a very reasonable and useful thing to do, from the perspective of both ease of coding and of code clarity.

      --
      See you, space cowboy...
    2. Re:autoboxing ? by BigBadDude · · Score: 5, Insightful


      ok, wait.

      how much time do you save for writting

      int i = e.next();

      instead of

      Integer ii = (Integer)e.next();
      int i = ii.intValue();

      probably few mintues per working day. I am not sure if this makes you code more clear because most of the time when you put something in a List/Array/whatever, you want to change its value and you cant do that with an automatically boxed type:

      e.next() ++;

      will simple not do what you intended so you will have to go back to casting Integers again. now THIS mixed use of two different methods will make you coding unreadable.

    3. Re:autoboxing ? by dkf · · Score: 2, Interesting

      The features add together. Taken as one, you can now just make a big extensible list of interesting integers and then do something with each of those list items, and you don't need to write lots of extra code to make it happen. You might not think this is a big deal, but it really helps in practice because it lets you write code that is closer to what you're thinking about instead of having to put in irritating book-keeping hoops all over the place. It's this sort of thing that makes languages like Perl, Python, REXX and Tcl so much more productive.

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    4. Re:autoboxing ? by random_static · · Score: 3, Insightful
      why is autoboxing so darn important to some people??
      because it makes compilers smarter. that in turn matters because it takes a load off of human optimizers, letting developers use higher-level languages with more impunity because getting decent performance out of them won't be quite so much work any longer.

      really, it's about machines learning (being taught to) do things humans get tired and bored doing - about automating more of the development process. that's good.

      if i want a hash-table of integers or a binary-tree of doubles, i will write it myself with the native types. it is faster,
      if that's actually true, you're either using a really shitty language or you're not very good at using it. higher-level features should be faster and easier to use, read, learn, and maintain; that's their whole point.
      and eats less memory.
      only if your compiler is too shitty to optimize the higher-level constructs properly. that's what autoboxing (among other things) is meant to fix.
    5. Re:autoboxing ? by a1englishman · · Score: 2, Insightful

      Autoboxing makes code far easier to read, and thus easier to maintain. If I have to wedge my way through pages of

      Integer ii = (Integer)e.next();
      int i = ii.intValue();

      it's a much bigger chore than reading a small amount of clear

      int i = e.next();

    6. Re:autoboxing ? by cakoose · · Score: 1

      I really don't understand how you can argue against autoboxing. Can you honestly say that your first code snippet is not clearer than your second? Also, your example was unnecessarily long and just hurt your case. You could have written:

      int i = e.next().intValue();

      But that still has an unnecessary method call that autoboxing will eliminate.

      ...you want to change its value and you cant do that with an automatically boxed type:

      e.next() ++;

      will simple not do what you intended so you will have to go back to casting Integers again. now THIS mixed use of two different methods will make you coding unreadable.

      The example doesn't work because the "++" operator only applies to storage elements (like variables and arrays). Ever tried doing "System.currentTimeMillis()++"? Java programmers are used to this because the collection APIs were never totally transparent (i.e. they never were as concise as array access); the Java language (like some others) doesn't support it because, unlike values, storage elements are not first-class.

      You don't have to "go back to casting Integers again." Going back to casting integers gives you nothing, because java.lang.Integer objects are immutable, just like int values. If all you have is an Enumeration or an Iterator, then you can't swap out elements of a Collection object. If you have an array, then I doubt you'd be taking advantage of autoboxing anyway. If you were using an ArrayList then compare the autoboxed way:

      list.set(index, list.get(index) + 1);

      ...to the old way (without even using the unnecessary cast that you, for some reason, decided to insert).

      Integer i = list.get(index);
      Integer j = new Integer(i.intValue() + 1);
      list.set(index, j);

      Even on one line, it's less readable:

      list.set(index, new Integer(list.get(index).intValue() + 1));

      Here, autoboxing can eliminate two conversions for you (one on the get and one on the set. I just can't understand why someone would want to explicitly write out the mechanical conversions that a compiler can perform for you (with 100% accuracy).

  3. One things Java needs... by xagon7 · · Score: 1, Insightful

    Is a fast GUI.... I have NOT looked at RC 5, but hope they have either sped up SWING... ...or even embrace IBM's Standard Widget Toolkit used in Eclipse.

    1. Re:One things Java needs... by ja · · Score: 5, Informative
      I have NOT looked at RC 5, but hope they have either sped up SWING...

      Linux and Solaris users, and new in beta2, Windows users, who have the latest OpenGL drivers and select graphic cards can get native hardware acceleration from Java2D using the following runtime property:

      java -Dsun.java2d.opengl=true -jar Java2D.jar

      mvh // Jens M Andreasen

      --

      send + more == money? ...
    2. Re:One things Java needs... by Anonymous Coward · · Score: 0

      Hm. Running the java 2D demo with OpenGL enabled just shows how badly Java2D performs compared to Qt 4's Arthur rendering engine when using OpenGL. The demo's are quite similar, but Java needs 100% processor time and gives me visible frames, while Qt doesn't even make the fan switch on and is quite smooth.

      I'm not impressed.

      Boudewijn

    3. Re:One things Java needs... by heffel · · Score: 3, Informative

      I downloaded RC 5 last night, and ran the
      SwingSetDemo. I noticed the GTK look and feel looks better than with JDK 1.4, it (more or less) uses the GTK theme you are using. I did notice a couple of bugs, sliders didn't display correctly, and the InternalFrames don't show up (the console displays a NullPointerException).

      I like the Swing API, but I don't like the emulated Look and Feel. I like the native look and feel of SWT, but I don't like the API. The best solution for someone like me is to use SwingWT.

      It is a wrapper around SWT, using the Swing API, porting existing Swing code to SwingWT is trivial,
      just replace java.awt.* with swingwt.* and javax.swing.* with swingwtx.swing.* and you are done.

      --
      Expert Java EE Consulting
    4. Re:One things Java needs... by dtfinch · · Score: 1

      I like the Swing API, but I don't like the emulated Look and Feel. I like the native look and feel of SWT, but I don't like the API. The best solution for someone like me is to use SwingWT.

      Looks interesting. I might try out the SwingWT + GCJ combo.

  4. Okay, nice, but... by Elamaton · · Score: 5, Interesting
    Well, if I'm going to learn Java properly, this might be as good a time as any. So far I've only scratched the surface with some trivial GUI apps a year and a half ago. Sure looks like I need to know it if I want to get a programming job around here (at least in Finland, it's Java, VB, C++ or C#, or another line of work - which sucks since I'm currently a PHP/Python man myself; and of the given alternatives, I'm only interested in Java).

    Getting a job would mean I'd have to learn J2EE as well (absolutely no one here is hiring plain J2SE people), and I honestly don't know how to go about it. Just looking at the TOC of Sun's J2EE tutorial is overwhelming with the enormous acronym soup, and judging by the articles I've read and by the quick glances I've taken at the types of literature available, learning it well seems to be nothing less than an impossible task.

    I remember seeing a graph depicting the ever-increasing requirements of a typical J2EE programmer compared to the actual skill levels of the current programmers. The gap is huge and ever widening, and I just know I'd be just one more lousy underperforming J2EE guy with my insufficient knowledge. Is it practically possible to learn the stuff in any other way besides doing it for a living, moving on up slowly from basic J2SE? Anyone here taken the leap, and how?

    I mean, you can't possibly know all that is J2EE properly. But what should one concentrate on, and roughly in what order? There's just TOO MUCH material, too many separate technologies, the practical purposes of which however overlap somewhat, and... I don't know, it's just too huge for my puny mind.

    And to go with the topic of the front page post even slightly: what does the new release of Java mean in the context of J2EE programming? What, if any, portions of the existing literature and other material does the new release make obsolete? And for J2SE literature, is there any fresh stuff that would be written with Java 5 in mind?

    Sigh... It's when things like this go through your mind that you wish you'd just be interested in something like plumbing as a career option, instead of programming. At least you'd always have work.

    1. Re:Okay, nice, but... by farnsworth · · Score: 4, Insightful
      J2EE is, by design, an enourmously complex API. I work with J2EE everyday, but almost no one I work with is good at more than about 50% of it.

      Is it practically possible to learn the stuff in any other way besides doing it for a living, moving on up slowly from basic J2SE? Anyone here taken the leap, and how?

      No, it's not. But that's not to say that you should not begin learning the API. J2EE covers HTTP...Server side web programming...Databases...Weird databases...Transactions...Distributed transactions...Distributed computing...Web services...Generated code...Annotated code...A ton of other stuff that I can't think of just this second.

      That's a lot! No one can be very good at any of this stuff, nevermind all of this stuff. The best you can do is dig in and solve some real problems that you have. You wont learn much from reading Sun's tutorials unless you can honestly say, "oh wow! I never though of doing it this way..." and you can never say that unless you actually tried to something some other way. (Side note: Sun's documentation is notorious for being way way way over-the-top in terms of academic "correctness" vis a vis practically solving a problem.)

      what should one concentrate on, and roughly in what order?

      I would recomend starting with common tools, like Ant, log4j, Struts, Eclipse. Then move on to the actual API and specs of topics like JDBC, Servlet/Jsp, JMS, and familiarizing yourself with various EJB containers.

      what does the new release of Java mean in the context of J2EE programming?

      In reality? Nothing. It takes J2EE vendors a very long time to catch up with the latest and greatest JVM. At work, I'm still using 1.3.2. Even when container vendors release products that real companies buy, The differences between 1.3 and 1.4 and 1.5 are not that huge for a developer. There are lots of nice improvements, but nothing that you'll have a hard time with.

      The bottom line is that if you can get good at a select few APIs, and are really really good at the tools, you'll have no problem ramping up on any of the other areas of J2EE.

      --

      There aint no pancake so thin it doesn't have two sides.

    2. Re:Okay, nice, but... by Magnus+Reftel · · Score: 4, Informative
      mean, you can't possibly know all that is J2EE properly. But what should one concentrate on, and roughly in what order?

      The only part of J2EE I've actually used my self as a Java programmer is the parts related to servlets. Since you say you use PHP, I take it you're not new to web projects. I'd recommend that you start there - download Tomcat, and learn JSP with taglibs & scriptlets. Then, gradualy move to a three-layer acrhitecture with chaining servlets and JSP for generating HTML only. (I learned PHP by rewriting my pet Servlet project in PHP, maybe the reverse could work for you?)

      Ignore Java 5 for now - it usually takes quite a while for new Java versions to get used in production, especially with J2EE, where you pretty much have to wait for app servers to support new versions before you can even cosider using them yourself.

      --
      print "Yet another p{erl,ython} hacker\n",
    3. Re:Okay, nice, but... by Scarblac · · Score: 4, Interesting

      I did one big J2EE project. We used Struts. There was one book that was very useful to me, and it's pretty short and affordable - _The Struts Framework: Practical Guide for Java Programmers_ by Sue Spielman. I can recommend it, it has a good overview and some details of all the little parts.

      I learned what a servlet is and how it works from the Sun tutorials, I think. Using Struts you won't make many pure servlets but it's important to have basic knowledge of what happens. Do the tutorial. Same for JSPs (they get compiled to servlets, you can make a JSP, run it, and look at the source of the servlet, if you really want to).

      We simply ran on Tomcat. Just install it and learn by online documentation. It of course has its pros and cons, but I can't really compare since I haven't used any other servers. It's a good start.

      Of course, always keep Sun's API reference pages close.

      As a layer between the OO Java parts and the database (MySQL in this case) we used a library called Torque. The idea is elegant and Torque is easy to learn, but it's slow and can become quite irritating. There are other options but I can't recall the names right now, and I think they are more complex.

      I never did find out what an EJB is.

      Oh, and these web apps can be hard to debug because of all the layers - setup Jython (a matter of putting the .jar somewhere and setting up the classpath correctly) so that you can call all your business code from a Python interactive prompt!

      --
      I believe posters are recognized by their sig. So I made one.
    4. Re:Okay, nice, but... by archeopterix · · Score: 4, Interesting
      Is it practically possible to learn the stuff in any other way besides doing it for a living, moving on up slowly from basic J2SE? Anyone here taken the leap, and how?
      I took the leap from a very basic Java knowledge (some hello worlds) to J2EE. Some hints:

      1. Motivation. Motivation helps. There's no motivation like being on an important project that uses J2EE, but this of course is usually beyond your control, unless you want to bluff your way into such a project (not recommended).

      2. Books. Avoid learning anything from pure specs. The books that helped me: "Java Enterprise in a Nutshell" from O'Reilly (Nutshell my ass, that's the thickest book in my room). "Enterprise JavaBeans" from O'Reilly, "Bitter EJB" (can't grab it now, so no details).

      3. Practice. I downloaded the Websphere Studio Application Developer (trial version) from IBM and started monkeying with it the moment I've heard about J2EE being used in the new project.

      4. Forget the APIs (at least their details). Try to make a mental map of the most important stuff - Container, Client, Beans and how they relate to each other. Once you got that, you can fill the details like APIs & such.
    5. Re:Okay, nice, but... by Anonymous Coward · · Score: 0, Insightful
      I did one big J2EE project. We used Struts ... I never did find out what an EJB is.

      I know that the servlet spec is part of J2EE proper, but I would not consider a webapp talking to mysql a "big J2EE project". Did you do any fine-grained security? Did you share running code accross jvms? Did you do distributed transactions? Did you use any kind of messaging API? Did you use any RPC? Did you use any SOAP/WSDL/Web service?

      With all due respect, unless you can answer "yes" to at least a couple of the above, I don't think anyone would take the "big J2EE project" bit seriously

    6. Re:Okay, nice, but... by dkf · · Score: 3, Informative
      I never did find out what an EJB is.
      EJB is a scheme for writing complex business logic in Java. Basically you write the code that does the interesting bits yourself, and then deploy the code into an application called an EJB container which handles most of the boring difficult bits like database integration, transaction management, user authentication and authorization, load balancing, multi-protocol serialization, object discovery, etc.
      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    7. Re:Okay, nice, but... by Scarblac · · Score: 2, Interesting

      That's fine. I realized after posting that our thing wasn't really "big" compared to the sort of thing J2EE can be used for, but Slash doesn't allow editing posts of course. It was big for us since the web app is used for order management, inventory control, etc everywhere in the company (a computer hardware web shop) and is also the site itself. It's about three man years of work, which is the biggest project I have experience with, but indeed not the sort of huge thing you would associate J2EE with.

      That said, for someone who can't see the forest for the trees and who needs a place to start, might as well look into that sort of thing and figure out what else to look at later.

      --
      I believe posters are recognized by their sig. So I made one.
    8. Re:Okay, nice, but... by Tomahawk · · Score: 3, Interesting

      what does the new release of Java mean in the context of J2EE programming?

      Sun have not yet released an updated version of the J2EE spec, and probably won't for a long time. As a result, Java 1.5 (or Java 5) will have no affect on J2EE for probably at least a year.

      The J2EE 1.4 spec was released last year, and not very many vendors had adopted it yet. I do J2EE programming here, and I still refer to the J2EE 1.3 docs for the API - I haven't found I've needed anything in 1.4 yet (even though our container are 1.4 complient).

      JVMs and J2EE containers are quite tricky little buggers, and generally don't work to well together with different version numbers. Most J2EE 1.3 containers won't work well with JVM 1.4 - I think it's because the J2EE stuff is very low level, and really needs the JVM to be the correct version (though I haven't tested a J2EE 1.4 container running on JVM1.3 - chances are some of the API required that is new in 1.4 won't be there, so it won't work that way either).

      So, SUN won't even begin to think about releasing a J2EE 1.5 until they have Java 1.5 in the bag, and probably not even until Java 1.5.1 has been released.

      T.

    9. Re:Okay, nice, but... by heffel · · Score: 1

      I'm not sure what is popular in Finland, but
      here in the USA, most J2EE projects involve Servlets, JSPs and EJBs (by far the most popular type of EJB are stateless session beans, most places stay away from Entity Beans). Many shops use Struts as well.

      Download JBoss or JOnAS (open source J2EE App Servers) and get some experience on the above technologies.

      One tool that will make your life a lot easier is XDoclet, but I would recommend that you do things "the hard way" a couple of times before you start using it.

      --
      Expert Java EE Consulting
    10. Re:Okay, nice, but... by heffel · · Score: 1

      I'm not sure what is popular in Finland, but
      here in the USA, most J2EE projects involve Servlets, JSPs and EJBs (by far the most popular type of EJB are stateless session beans, most places stay away from Entity Beans). Many shops use Struts as well.

      Download JBoss or JOnAS (open source J2EE App Servers) and get some experience on the above technologies.

      One tool that will make your life a lot easier is XDoclet, but I would recommend that you do things "the hard way" a couple of times before you start using it.

      --
      Expert Java EE Consulting
    11. Re:Okay, nice, but... by xod · · Score: 1

      I suggest you start with a small project on your own. Download a copy of Orion as it's a full-powered J2EE server but by far the easiest to get running. Write a JSP or two, and build a simple servlet. Use the built-in hsql database, and learn some simple JDBC access. Don't fret taglibs yet, they're rarely used. Try to avoid the temptation to use jakarta projects, except for ant. After you get comfortable with all that, then learn EJB.

    12. Re:Okay, nice, but... by EvlG · · Score: 2, Insightful

      Too bad that some programmers' interesting bits are other programmers' boring bits....

      Screw business logic. Coding up all that other stuff sounds very interesting to me.

    13. Re:Okay, nice, but... by Anonymous Coward · · Score: 0

      You can skip EJB. I have been on three very large projects now where large investments in EJB have been abandoned in favor of simpler frameworks. The best is at http://www.springframework.com.
      EJB was designed to bring in consulting revenue for Sun, IBM and Oracle. It is deliberately more complex than necessary. Do your employer a favor and point them to a modern framework.

    14. Re:Okay, nice, but... by GCP · · Score: 1

      Well, while you're at it, why don't you write your own operating system, too? ;-)

      --
      "Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
    15. Re:Okay, nice, but... by Anonymous Coward · · Score: 2, Insightful

      Forget the EJB containers. I have participated in three very large projects now where large investments in EJB code were completely abandoned in favor of lightweight frameworks. The best of these is at http://www.springframework.com.
      The only thing you can do with an EJB container that you can't do in a lightweight framework is distributed transactions. And the EJB performance at this is so poor you would be better off using web services for remote calls.

    16. Re:Okay, nice, but... by Scarblac · · Score: 1

      Perhaps, but what IS an EJB?

      I know what a bean is - crudely said, an object with properties with getters and setters. A really simple concept.

      But start reading about EJBs, and it immediately becomes very very foggy... could you point me towards one really concrete example of a typical EJB?

      --
      I believe posters are recognized by their sig. So I made one.
    17. Re:Okay, nice, but... by EvlG · · Score: 1

      That also sounds quite appealing!

    18. Re:Okay, nice, but... by chickenwing · · Score: 1

      Don't bother learning things just so you can check off a bunch of buzzwords. Get a really solid handle on the language first and learn the idioms.

      I would be more impressed with someone who can write a container than one who knows how to do some J2EE stuff but has no clue about what is really going on.

      I would suggest that you do a bunch of personal projects that each pushed a little beyond your abilities at the time. For example, after getting the hang of writing a standalone application try writing a server program that communicates over a socket. Then maybe one program with two servers that can be upgraded independantly.

      After you feel like you have a solid understanding of the J2SE, take a look at things like J2EE and see whats there, maybe try it out, and then go back and see if you understand how you would implement some of the functionality you have seen.

      Try to avoid getting sucked into the hoopla behind the latest buzzwords. I think a solid understanding of the fundamentals (not just in a particular language) and genuine interest will win out in the end. Also daring to be different can really separate you from the pack.

    19. Re:Okay, nice, but... by Anonymous Coward · · Score: 0

      > Perhaps, but what IS an EJB?

      A dead technology. -- It was designed to solve a problem that nobody really has.

      You can ignore it.

    20. Re:Okay, nice, but... by Anonymous Coward · · Score: 1, Interesting
      At work, I'm still using 1.3.2.

      Oh man, I hear ya. We're still on 1.3.x in my shop too (large US bank), and have no plans to upgrade to 1.4.x until at least a year after IBM releases Websphere 6.0.

      And the new Java 5? I think NASA will have a working space elevator before we see that in my shop. :-)

    21. Re:Okay, nice, but... by dkf · · Score: 1

      So? If you want to code up an EJB container that's fine with me. There's even an OSS container (JBoss) if you want to build off other people's work.

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
  5. Eclipse support by HRbnjR · · Score: 4, Insightful

    This is great, but what I would really like to see, to make this useful for me, is support within Eclipse (it's parser/compiler chokes on 1.5 code features right now). And for those of you sharing my anticipation here is the bug from Eclipse's bugzilla for tracking the support.

    1. Re:Eclipse support by whitelines · · Score: 1

      You have to get one of the stream builds and add a plugin. Check This guide for details.

      --
      /* TBD */
  6. Remember when C# came out... by km790816 · · Score: 2, Interesting

    And everyone said it was a shameless copy of Java.

    Enums, autoboxing of primitive types, and metadata...I suppose this is "inovation", right? There was no shameless copying of C# in any of these new features. It was all about customer demand.

    I'm not not putting down Java. I'm just saying one should think twice before judging the demands of a customer segment. I'd just like to see a feature list of things not in C# so I can see some original thinking on Sun's part.

    --
    A speech...
    1. Re:Remember when C# came out... by BigBadDude · · Score: 0

      most of the stuff you mentioned had been planned to be included in the next releases of java long long time before C# was born.

      I use both Java and C#. And to me it looks like Microsoft put every possible feature into C# without thinking so it could say "look, unlike Java, C# has xxx and yyy".

      as a whole, the java implementations are much more usefull in practice (and less dangerous)

    2. Re:Remember when C# came out... by dedazo · · Score: 1
      most of the stuff you mentioned had been planned to be included in the next releases of java long long time before C# was born.

      C# was "born" in 1998 or thereabouts. If you mean the first base language spec.

      the java implementations are much more usefull in practice (and less dangerous)

      How cute.

      --
      Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
    3. Re:Remember when C# came out... by tomee · · Score: 2, Funny

      Let's compromise: They were shameless innovations, ok?

    4. Re:Remember when C# came out... by GCP · · Score: 4, Insightful

      most of the stuff you mentioned had been planned to be included in the next releases of java long long time before C# was born.

      No, it wasn't. It's not that Sun had never considered these features. They had considered them and rejected (most of) them.

      As long as there was no direct competition, Sun was famous for repeatedly informing developers (like me) who requested most of these things that they "didn't get it" and that they knew what we really needed better than we did, and we didn't need these things. They talked about "language stability" and how extreme the circumstances would have to be to get them to make any change in the Java language, which had undergone no changes since 1.1.

      Well, that "extreme circumstance" was serious competition in the form of C#. When Sun claims that they are not copying C# they are correct in the sense that they didn't have to be shown *how* to do these things, but without C# they would have gone on telling us "no" for a very long time.

      --
      "Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
    5. Re:Remember when C# came out... by dkf · · Score: 1

      What C# did was tip the balance between the keep-it-all-static guys and the put-new-features-in guys. Let's not forget that keeping the language static has many advantages, notably that it is much easier to write tools that work with the language (e.g. Eclipse).

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    6. Re:Remember when C# came out... by be-fan · · Score: 3, Insightful

      Enums, autoboxing of primitive types, and metadata...I suppose this is "inovation", right? There was no shameless copying of C# in any of these new features. It was all about customer demand.

      Well, they weren't innovative when Microsoft did it, so they sure as hell aren't innovtative now. More generally, it'll be at least another decade before Sun or MS put a feature into C# or Java that wasn't already in Lisp or ML a decade ago.

      --
      A deep unwavering belief is a sure sign you're missing something...
  7. Tiger? by Power+Everywhere · · Score: 2, Insightful

    So assuming Apple is keeping up with Sun, Java 5 should work with Mac OS X v10.4, and Tiger will run on Tiger.

    How confusing.

    --

    BLING BLING. Meet the architecture that's changing everything.

  8. J2EE and how to go about learning it. by tod_miller · · Score: 2, Informative

    I definately suggest putting J2EE on the back burner! Its like trying to swim in the deep end, with sharks, man-o-wars, rusty WW2 sea mines, the Southhampton Elderly Aquarobics class, toddler swimming lessons and a huge inflatable Barney (TM).

    Start with Java SE, definately play with Swing, then move onto servlet and JSP, keeping it simple, I suggest using the java.sun.com leanring trails or some O'Reilly books.

    Donwload Tomcat 5... when you are good at that, do some JSTL in the mix, work on a struts application using just a dto layer, then think about J2EE, which is all that plus an EJB container (lookup EJB's) and lots of knowledge of design patterns, like fast lane readers, session facades (limiting network overheads etc) and then you can call yourself a J2EE programmer.

    "It's when things like this go through your mind that you wish you'd just be interested in something like plumbing as a career option, instead of programming. At least you'd always have work."

    I would have, but I was told my ass-cleavage was too good and I could get kicked out of the union... shame really.

    Plumbers seem to have ace jobs in all the porn movies I have seen, but I haven't the face for a handlebar moustache.

    --
    #hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
  9. Where to start by Phouk · · Score: 3, Interesting

    mean, you can't possibly know all that is J2EE properly. But what should one concentrate on, and roughly in what order?

    First, "J2EE" can mean two things. Some people use as a somewhat sloppy catch-all-term for "server-side Java", but really just mean something like e.g. Java/JSP/Servlets/Struts/Hibernate/Tomcat. Some reserve "J2EE" for projects which, in addition, use EJBs and a full-blown J2EE server like JBoss, which Tomcat is not.

    Why is this relevant? Because, of course, the second variant includes even more stuff, but many many projects use the first variant, so I would start with that and ignore EJBs for the moment.

    But even the technologies in a project of the first kind are too many and too big to learn all at once, so I would pick one end to start from, either from the frontend (HTML etc. -> JSP, JSTL -> Custom Tags, Servlets -> e.g. Struts etc.) or from the backend (DB/SQL -> JDBC -> Hibernate||JDO||iBatis... -> etc.), and only later expand up (EJB) and out (know back to front and more frameworks).

    And, remember: Q: How do you eat an elephant? A: One bite at a time...

    --
    Stupidity is mis-underestimated.
  10. There's one feature I can't WAIT to start using .. by arhar · · Score: 1
    ... typed lists. I'm so sick and tired of operating with Lists, ArrayLists and Vectors and then writing
    return (Foo[]) list.toArray(new Foo[list.size()]);
  11. Re:There's one feature I can't WAIT to start using by bonniot · · Score: 3, Interesting
    Unfortunately, with Java 5 you will still need to write
    return list.toArray(new Foo[list.size()]);
    since list.toArray() still returns an Object[]. That's because of the restriction that forbids new T[...]. Of course, with a more advanced language, you could simply write
    return list.toArray();
    and let the compiler do the work for you.
    --
    Watch great movie opening scenes!
  12. What's been changed from beta 2? by prat393 · · Score: 1

    I mean great, I've heard all about the nice new changes to the 1.5/5.0 series, but what bugs did Sun fix between beta 2 and RC1 (since I'm sure there'll be an RC2 before the release, there always is).

    1. Re:What's been changed from beta 2? by aled · · Score: 1

      They seem to forgot to update the bug fixes link in the release notes. Usually there's detailed information, even in the development snapshots.

      --

      "I think this line is mostly filler"
  13. More useful links by prat393 · · Score: 4, Informative
    If you feel like a more in-detail look at 1.5, these documents might be useful:
  14. Start with the most useful 20% of J2EE by chris+huntley · · Score: 1

    Most of J2EE is over-engineered for everyday usage, intended to be used only occasionally and almost never if you're not working on very large-scale apps. As long as you're comfortable with databases you can learn most of the useful stuff from developing a few small database-backed web apps. The idea is to see the various tiers and how they fit together, not to build a professional-quality web app. Do that later after you've read a bit and looked at a few real, working J2EE apps. A good place to start reading is with Rod Johnson's book on J2EE without EJB, where he makes several practical recommendations of open source tools, libraries, and frameworks that should cut through most of the complexity for you. Unfortunately, since he does spend a lot of his time comparing other technologies to EJB, you may find yourself skipping around a bit. Don't worry about it: that part is for those who have already anchored on EJB and does not (necessarily) apply to you. After getting an overview from Johnson's book, you might want to read up on some of the things he covers in his book: Hibernate or JDO for persistence, Spring or PicoContainer for a lightweight container/services framework, Struts or SpringMVC or WebWork for the web tier. There are plenty of books on these things, including some very good ones from Manning. Good luck. J2EE is like a huge casino. There's lots of stuff in there to do, but you will likely only spend your time at a few tables. Pick well and you can have a good time without losing your shirt.

  15. Sun's SSL certificates borked? by cortana · · Score: 1

    When I try to download the packages, I am told that the certificate could not be validated with OSCP. Anyone else seeing this?

  16. Re:There's one feature I can't WAIT to start using by Ahe · · Score: 2, Informative

    We're looking into it: 5072831

  17. Jeez! Hypersensitive Moderators by fm6 · · Score: 1

    Graham Hamilton really does collect hats and stuffed wallabies. Used to work down the hall from the dude.

  18. Other archs? by Nicopa · · Score: 1

    Any news of when it will be released for other archs... e.g. I'll probably have to wait for it to be released for Tru64 4 =(.

  19. Re:There's one feature I can't WAIT to start using by Anonymous Coward · · Score: 0

    The feature *I* would love would be String continuation systax.

  20. Re:There's one feature I can't WAIT to start using by bonniot · · Score: 1

    You mean multiline string literals?

    --
    Watch great movie opening scenes!