Java2 SDK v. 1.4 Released

pangloss writes: "Yay: XML, built-in Perl-ish regex, jdbc 3.0, asserts, IPv6, lots of other goodies. Release notes and incompatibilities. And I think this means I can use my wheel-mouse in NetBeans without that extra module ;) Download it here." WilsonSD adds: "There are many cool new features including a New I/O package, an Assert Facility and enhanced performance." Some other random Java notes: O'Reilly has an essay about why you won't see any open source J2EE implementations, and Kodak has filed a patent-infringement claim against Sun regarding Java.

Re:It's a big step up, but there is still distance

[Anonymous Coward]

SSL at the Java level IMHO is stupid. Set up secure tunnelling whenever the data leaves your trusted zone, and have it be done in hardware or optimized (C) software.

Genericity?

[hephro]

And still no generic data structures (a.k.a. templates in the C++ world)... all those explicit downcasts from Object hurt and need to be optimized away by the JIT...

-Hein

It's a Release Candidate

[DamageBoy]

This release is not a fina stable release.
It's just the RC:
http://java.sun.com/j2se/1.4/download.html [sun.com]
It's been there for the past two weeks.
You call this news?

My pet peeve.

[Malcontent]

This is in regard to the kodak suit.

What I find especially bothersome is the the fact that Koday (supposedly) had these patents. They did nothing with them. Sun produced a product, hyped it, sold it, improved it and put in millions of dollars and man hours into it.
Kodak then comes in and demands money after the fact when they made no attempt to actually do anything.

I think that's crazy. Why punish the people who got off their asses and did something especially if the punisher was too lazy or stupid to actually make use of their idea.

This isn't just about sun and kodak either. Who was suing palm recently? Same thing.

Sit on your ass doing nothing, wait for somebody else to do all the work. Then sue them and retire in the bahamas. It's the american way I guess. Sure beats working.

Re:Kodak invented OLE?

[briansmith]

Kodac got these patents when it bought Wise. I read on JavaLobby.com's discussion of the lawsuit that Wise sued Microsoft three years ago over these three patents. I don't know the outcome of the alleged lawsuit.

Also, a few people on JavaLobby are of the opinion that Kodac just patented three fundemental object-oriented programming techniques. If that is the case, these patents would never hold up in court as almost any SmallTalk program written before 1990 would be prior art.

Re:My take on JDK 1.4

[briansmith]

As far as C# vs .Java. I am really impressed with the CLR/CLI stuff. Right now, as it stands, Java is a proprietary language. Unless we see SUN Open Source Java (or push it through a standards committee), we *may* see a JDK 1.5... but no one will use it.

I agreed with your whole post except for this statement. It is just FUD (perhaps unintentional). The fact is that CLR/CLI isn't going to kill off Java in the next 16 months, which is when I expect to see JDK 1.5 delivered. Also, there is nothing stopping open-source clean-room implementations of anything in J2SE, AFAICT. You just can't call your product "Java" and you won't be able to get your runtime certified by Sun. Similarly, I doubt that Microsoft will let somewhat create a clean-room CLR/CLI and call it "The .NET Framework", and they don't even have a process in place for certifying compatible implementations.

Re:J2EE openness

[customiser]

Sun certification does not have any effect on JBoss's functionality. As I see it, it is just a marketing matter, being able to say "This is a Sun certified J2EE App Server", so that whoever makes the decision on using it (and mainly commercial organisations) can be confident that it really does what it is supposed to do.

btw, as it is a server, it does not run on the client.

Ruby vs. Java

[srichman]

I'm a big fan of Ruby, and a diehard Java devotee.

But I can't forsee Ruby supplanting Java for large projects. The typing is too dynamic, and this ends up being a big headache and source of problems in larger code bases. More concertely, the lack of compile-time type checking makes it hard for Ruby to scale to big projects. You don't find out until runtime if something is type correct, and even then maybe not until some rare execution sequence occurs. Or, worse, it might be type correct in the Ruby sense (i.e., an object can receive a certain message), but not be at all type correct from the programmer's point of view, which might manifest itself in difficult-to-find bugs.

This is a problem with dynamic casting in Java/C++, too, but in those languages the dynamic type checking is the exception rather than the rule (this will get a lot better when Java introduces parametric types in 1.5). More fundamentally, though, at least those languages offer compile-time type checking support, whereas Ruby does not and cannot (since code can be dynamically injected into objects).

Re:My take on JDK 1.4

[Richard_Davies]

Regarding the logging and regex packages: Just because a package is less functional does not mean that it is intrinsically bad. If the package is suitable for the majority of uses by the majority of developers, then it's probably OK - after all, it's easier for someone to learn a small package rather than a large one. If you require something more specific, then you are still free to use the packages you metnioned. The JDK logging and regex packages ADD choice - surely this is a "good thing"?

Please take a close look at both the openess of .NET and the multilanguage capabilities. Neither are everything they are cracked up to be. Only the CLR and a "core" set of C# classes are open - everything else (i.e. the really useful bits that everyone needs) are not. My question - do you trust Microsoft to open these up?

You mention (must have seen this somewhere before on Slashdot :-) that Java should be Open Source / Standardised. I, like many Java developers have no instrinsic problem with this. However, there is the issue of cross-platform portability:

Many people complained when Sun would release a JDK for Windows and Solaris that it didn't have one of Linux. Then they complained when a Linux JDK was created that it didn't come out at the same time. Now with Sun releasing all 3 JDK simeltaneously (and the likes of Apple and IBM not usually far behind), consider this:

How likely do you think this situation would be if the JCP (or something like it) was not in place? Do you really think you would be saying "As far as that... it runs GREAT on Linux. Probably the most SOLID VM I have ever run." if Java was Open Source?

Maybe it would be:
"Well the Linux version is pretty good - can't use the xyz library because that's Windows only and it will probably be out of beta only 6 months after the Windows version but hey - it's Open Source! That make me FEEL GOOD!"

What I would LOVE is to see Java open sources while ensuring that it remains cross-platform. While some would claim that open source would guantee that, it is not provable. Sun believes that there is too much risk. While you may not, agree with that you have Java that is:

a) free (as in beer)
b) you can read the source code the the whole API
c) you can change (but not distribute) the source
d) works on all major plaforms (including FreeBSD now BTW)

For me, and many other Java developers, these still place it far ahead of anything Microsoft is doing - and while Mono iterests me, its going to be a LONG time before it can match Java's (or even .Net's) current functionality.

Unit testing

[Aapje]

I've never used assertions, but they seem a great complement to unit testing. Unit testing allows you to write code to test your functions and easily see if something breaks, the major problem is that they lack an easy way to look inside objects to keep an eye on internal consistency. Assertions can be great to catch those silly little boundary mistakes.

A good unit testing framework for Java is JUnit [junit.org], they are available for other languages as well.

BTW, you can create your own assertions with Log4J [apache.org], so even JDK 1.1/1.2/1.3 users can use them:

if(logger.isDebugEnabled())
if (bla>10)
logger.warn("bla>10, bla=" + bla);

This uses almost no CPU-time if debugging is disabled. Log4J is a very good logging package, it surely beats System.out.println, check it out!

Re:Java Secure Socket Extension

[Anonymous Coward]

JSSE is integrated, and does suport SSL, but the point being made is that fact that JSSE was not updated to support non-blocking I/O. So all the talk about how non-blocking I/O is gonna be this great boon for server programmers is somewhat moot, since they don't do SSL outta the box and developing SSL isn't as easy as just encrypting data.

There is an RFE I entered about this a while back http://developer.java.sun.com/developer/bugParade/ bugs/4495742.html . If you're a Java developer, register and vote for it, to make sure Sun corrects this oversight.

Still didn't fix it...

[Xawen]

Ok, so 1.4 may be faster. 1.4 may be more stable on Linux. 1.4 may be more robust. But, they still didn't fix the thing that annoys me the most about Java. Why is it so freaking complicated to do a simple read from the keyboard???

Still no GUI fixes?

[fluor2]

I hate to say it, but I've still not seen a single java application with a lot of windows (using the GUI) perform well under my MS Windows. I know this is not Windows' fault, since they also seem to lag under Linux.

My class and I was at Sun Microsystems in Ireland in 2001. They talked a lot about how good Java was. But when I asked one of the top people this simple question "Why isn't staroffice programmed in Java?", they said "We don't know, actually".

I know why. It's because Java just can't compete with faster languages when it comes to larger programs that require real window handlement. (personal opinion ofcourse).

Now on to the "so-called" platform independability. I personally have been asked several times to convert java programs so they can be run on UNIX platforms (like HP-UX) because they just didnt perform well on those platforms. Instead we chose TCL or similar. Which seem to do the job.

Best luck to Java in the future. Hope you programmers can fix these "small" problems :-).

Re: enums and Java

[flagstone]

if I defined all the enum lables as finals in Java, and then used them in switch statements/assigns on variables, I don't get the type-checking I do in C. So in C:

enum PersonType aPerson = Desktop;

would be flagged as an error, but in Java the equivalent

int PersonType = DESKTOP;

would be perfectly fine as far as the compiler is concerned.
This could be a problem.

True, which is why you shouldn't do enumerations in Java that way :-). See this article [javaworld.com] for a description of how to do typesafe enumerations. However, as is pointed out in the article, you still must do more work in Java than in C++ to accomplish this.

Re:Genericity?

[Elbows]

On large projects it can be a big issue. Someone
puts an instance of class X in a vector that's
really meant to be holding class Y. No exception
is thrown until you access the bad data and try
to cast it to a Y, at which point there's no good
way to find out where the error occurred.

Now you have to dig through 100k lines of code
to find the mistake. With generics it's caught at
compile-time.

That said, generics should be implemented so as
to give you performance, too. If you know
everything in a collection is an X, there's no
reason to do any casting at all.