Java 5 RC Available, Gold Targeted for this Month

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

Comments

Are people still using java?

[kiddygrinder]

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!

autoboxing ?

[BigBadDude]

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 ?

[rmull]

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 ?

[BigBadDude]

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 ?

[dkf]

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.

Re:autoboxing ?

[random_static]

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.

Re:autoboxing ?

[a1englishman]

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();

Okay, nice, but...

[Elamaton]

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

[farnsworth]

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

[Magnus Reftel]

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

[Scarblac]

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

[archeopterix]

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.

Re:Okay, nice, but...

[dkf]

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

[Scarblac]

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.

Re:Okay, nice, but...

[Tomahawk]

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.

Re:Okay, nice, but...

[EvlG]

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.

Re:Okay, nice, but...

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

Eclipse support

[HRbnjR]

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.

Remember when C# came out...

[km790816]

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.

Re:Remember when C# came out...

[tomee]

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

Re:Remember when C# came out...

[GCP]

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.

Re:Remember when C# came out...

[be-fan]

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?

[Power Everywhere]

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.

J2EE and how to go about learning it.

[tod_miller]

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.

Where to start

[Phouk]

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:One things Java needs...

[ja]

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

[heffel]

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.

Re:There's one feature I can't WAIT to start using

[bonniot]

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.

More useful links

[prat393]

If you feel like a more in-detail look at 1.5, these documents might be useful:

• J2SE 5 New Features
• JDK 5.0 Release Notes (warning: not updated for the release candidate)

Re:There's one feature I can't WAIT to start using

[Ahe]

We're looking into it: 5072831