Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Java Programming Sun Microsystems Upgrades

Java 5 RC Available, Gold Targeted for this Month 65

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

Java 5 RC Available, Gold Targeted for this Month More

Java 5 RC Available, Gold Targeted for this Month

Comments Filter:

  • Are people still using java? (Score:4, Funny)

    by kiddygrinder ( 605598 ) on Friday September 03, 2004 @01:28AM (#10146776)
    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!
    • 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.

  • autoboxing ? (Score:4, Interesting)

    by BigBadDude ( 683684 ) on Friday September 03, 2004 @01:37AM (#10146808)


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

    • Re:autoboxing ? (Score:5, Interesting)

      by rmull ( 26174 ) on Friday September 03, 2004 @01:51AM (#10146850) Homepage
      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.

      • Re:autoboxing ? (Score:5, Insightful)

        by BigBadDude ( 683684 ) on Friday September 03, 2004 @02:03AM (#10146900)

        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.

        • Re:autoboxing ? (Score:3, Interesting)

          by dkf ( 304284 )
          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, Py

        • Re:autoboxing ? (Score:2, Insightful)

          by a1englishman ( 209505 )
          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();

        • 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 ha

    • Re:autoboxing ? (Score:3, Insightful)

      by random_static ( 604731 )

      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 integ

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

    • Re:One things Java needs... (Score:5, Informative)

      by ja ( 14684 ) on Friday September 03, 2004 @04:05AM (#10147248) Homepage
      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

    • Re:One things Java needs... (Score:4, Informative)

      by heffel ( 83440 ) <dheffelfinger@en ... AWet minus berry> on Friday September 03, 2004 @07:37AM (#10148011) Homepage Journal
      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 [sourceforge.net].

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

  • Okay, nice, but... (Score:5, Interesting)

    by Elamaton ( 771817 ) on Friday September 03, 2004 @01:46AM (#10146827)
    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.

    • Re:Okay, nice, but... (Score:5, Insightful)

      by farnsworth ( 558449 ) on Friday September 03, 2004 @02:48AM (#10147016)
      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.

      • Re:Okay, nice, but... (Score:2, Insightful)

        by Anonymous Coward
        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.

      • Re:Okay, nice, but... (Score:1, Interesting)

        by Anonymous Coward
        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. :-)

    • Re:Okay, nice, but... (Score:4, Informative)

      by Magnus Reftel ( 143 ) on Friday September 03, 2004 @02:49AM (#10147019)
      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.

    • Re:Okay, nice, but... (Score:5, Interesting)

      by Scarblac ( 122480 ) <slashdot@gerlich.nl> on Friday September 03, 2004 @03:06AM (#10147052) Homepage

      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!

      • Re:Okay, nice, but... (Score:4, Informative)

        by dkf ( 304284 ) <donal.k.fellows@manchester.ac.uk> on Friday September 03, 2004 @05:15AM (#10147487) Homepage
        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.

    • Re:Okay, nice, but... (Score:5, Interesting)

      by archeopterix ( 594938 ) * on Friday September 03, 2004 @03:12AM (#10147067) Journal
      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.
    • 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 applic

    • Where to start (Score:4, Interesting)

      by Phouk ( 118940 ) on Friday September 03, 2004 @04:04AM (#10147242)

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

    • Re:Okay, nice, but... (Score:4, Interesting)

      by Tomahawk ( 1343 ) * on Friday September 03, 2004 @06:37AM (#10147757) Homepage
      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.
    • 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 [sourceforge.net], but I would recommend that you do things "the hard way" a couple of times before you start usin
    • 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 [sourceforge.net], but I would recommend that you do things "the hard way" a couple of times before you start usin
    • 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 re
    • I suggest you start with a small project on your own. Download a copy of Orion [orionserver.com] 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.
    • 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 serv

  • Eclipse support (Score:5, Insightful)

    by HRbnjR ( 12398 ) <chris@hubick.com> on Friday September 03, 2004 @01:46AM (#10146832) Homepage
    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 [eclipse.org] from Eclipse's bugzilla for tracking the support.

  • Remember when C# came out... (Score:3, Interesting)

    by km790816 ( 78280 ) <[moc.liamekaens] [ta] [20xg3qhqw]> on Friday September 03, 2004 @01:50AM (#10146845)
    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.
    • Let's compromise: They were shameless innovations, ok?

    • Re:Remember when C# came out... (Score:4, Insightful)

      by be-fan ( 61476 ) on Friday September 03, 2004 @03:23PM (#10152663)
      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.

  • Tiger? (Score:2, Insightful)

    by Power Everywhere ( 778645 )
    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.
  • ... 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()]);
  • 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).

  • More useful links (Score:5, Informative)

    by prat393 ( 757559 ) on Friday September 03, 2004 @08:54AM (#10148571)
    If you feel like a more in-detail look at 1.5, these documents might be useful:
  • When I try to download the packages, I am told that the certificate could not be validated with OSCP. Anyone else seeing this?
  • 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 =(.

Slashdot Top Deals

"Being against torture ought to be sort of a multipartisan thing." -- Karl Lehenbauer, as amended by Jeff Daiell, a Libertarian

Close