Slashdot Mirror
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."
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.
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.
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.
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.
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.
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
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."
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 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. 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.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();
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.
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.
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...