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.

Yah, will this be stable on Linux?

SDK 1.3.1 stability was terrible on Redhat 7.1 and 7.2 Hopefully 1.4 will be much better. Otherwise I will have to continue using IBM's 1.3.0 SDK.

Re:Yah, will this be stable on Linux?

Of course it will be stable. Everything is stable under L---

kernel: VFS: Disk change detected on device fd(2,0)
kernel: end_request: I/O error, dev 02:00 (floppy), sector 0
kernel: VFS: Disk change detected on device fd(2,0)
kernel: end_request: I/O error, dev 02:00 (floppy), sector 0
kernel: Incorrect segment count at 0xc01781d6nr_segments is 15
kernel: counted segments is 17
kernel: Flags 0 0
kernel: Segment 0xc37ace40, blocks 4, addr 0x4bd1fff
kernel: Segment 0xc37acea0, blocks 4, addr 0x4bd27ff
kernel: Segment 0xc37ac780, blocks 4, addr 0x38abfff
kernel: Segment 0xc37acde0, blocks 4, addr 0x38ac7ff
kernel: Segment 0xc3809120, blocks 4, addr 0x1e77fff
kernel: Segment 0xc0e0fda0, blocks 4, addr 0x199c7ff
kernel: Segment 0xc3871ec0, blocks 4, addr 0x6fe2fff
kernel: Segment 0xc3871f20, blocks 4, addr 0x6fe37ff
kernel: Segment 0xc3871e00, blocks 4, addr 0x498afff
kernel: Segment 0xc0e0fec0, blocks 4, addr 0x18aefff
kernel: Segment 0xc3871c80, blocks 4, addr 0x41b6fff
kernel: Segment 0xc3871ce0, blocks 4, addr 0x41b77ff
kernel: Segment 0xc3871b60, blocks 4, addr 0x1d06fff
kernel: Segment 0xc0e0fe60, blocks 4, addr 0x18af7ff
kernel: Segment 0xc38719e0, blocks 4, addr 0x4c3ffff
kernel: Segment 0xc3871aa0, blocks 4, addr 0x4c407ff
kernel: Segment 0xc0e0ff20, blocks 4, addr 0x18ae7ff
kernel: Segment 0xc3871800, blocks 4, addr 0x4cb0fff
kernel: Segment 0xc3871860, blocks 4, addr 0x4cb17ff
kernel: Segment 0xc3871140, blocks 4, addr 0x4b8ffff
kernel: Segment 0xc38717a0, blocks 4, addr 0x4b907ff
kernel: Segment 0xc0e150c0, blocks 4, addr 0x196d7ff
kernel: Kernel panic: Ththththaats all folks. Too dangerous to continue.
kernel:
kernel: rq->cmd=1, rq->sector=73208, rq->nr_sectors=8
kernel: kernel BUG at pktcdvd.c:1046!
kernel: invalid operand: 0000
kernel: CPU: 0
kernel: EIP: 0010:[serial:__insmod_serial_S.bss_L3392+238989/37 155027]
kernel: EFLAGS: 00010086
kernel: eax: 0000001e ebx: c1273840 ecx: c4676000 edx: c020f384
kernel: esi: c208f09c edi: c208f074 ebp: c7f9d760 esp: c6fc3f88
kernel: ds: 0018 es: 0018 ss: 0018
kernel: Process pktcdvd0 (pid: 1303, stackpage=c6fc3000)
kernel: Stack: c8861c10 c8861d2f 00000416 c6fc2000 c208f09c c208f074 c208f000 c7f9d86c
kernel: c8860076 c208f074 00000f00 c762df1c c208f000 00000b00 c6fc3fe0 c208f008
kernel: c208f10c c7f9d778 00000000 c6fc2000 00000000 00000000 00000000 c6fc2000
kernel: Call Trace: [serial:__insmod_serial_S.bss_L3392+245712/3714830 4] [serial:__insmod_serial_S.bss_L3392+245999/3714801 7] [serial:__insmod_serial_S.bss_L3392+238646/3715537 0] [kernel_thread+40/56]
kernel:
kernel: Code: 0f 0b 83 c4 0c b8 06 00 00 00 0f ab 45 48 19 c0 85 c0 75 24

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

I've been working on a server that takes a lot of connections in Java, and you can finally do it with the support of "select" in Java 1.4. But no support for SSL. I undertand why it happens, but this "we'll get around to doing the security later" is why we don't have a lot of security.

Java will always present a dilemma. With the push for portability, you often have to wait for the platform itself to support things like this (select) or kludge it in very non portable ways. But that portability leaves the system behind which hurts it in competition with other systems more tolerant of innovation and the fracturing it brings.

A good philosophy would be to rule that every time a system library or feature needs to do something that an ordinary user can't do, they don't just build it in, they make a way that an ordinary user could write it. That paves the way for more innovation.

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

"I've been working on a server that takes a lot of connections in Java, and you can finally do it with the support of "select" in Java 1.4."

I've been using NBIO (Non-Blocking IO) [berkeley.edu] for quite some time, getting very good results. Been waiting for Java 1.4 to go final so I can start working with java.nio

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

It's worth noting that the Berkeley NBIO package was part of the research that led to the 1.4 java.nio package.

Also, using their package, and a very interesting partitioned, event-based coding style [berkeley.edu], they wrote, in Java, a web server [berkeley.edu] that out performs Apache (written in C).

Java Secure Socket Extension

The Java Secure Socket Extension has provided TLS/SSL support to Java for a long time, and is now part of 1.4 [sun.com].

???

hope swing is faster now / I prefer Ruby over Java

I hope that Swing is faster now under linux. I played with netbeans and jedit and although there are really good they are not very fast on linux. on a slower windows PC jedit stated much faster than on my linux box.
a few days ago I played a little with Ruby (the coolest language available IMHO) and Gtk+. although the bindings are not yet finished they work very well under Linux and this is much faster than Java/Swing.
Maybe Ruby is the future. At least I hope so. If Ruby gets more stable modules Ruby can be the Number One OOP language. It is cleaner than Perl or Java, the Programms are shorter, the Language is more intuitive and.... and.... and. This is only my humble opinion. See for yourself if you like ruby. check out http://www.ruby-lang.org

Summary of new features

A summary of all the new features is available here:
http://java.sun.com/j2se/1.4/docs/relnotes/feature s.html [sun.com]

Articles about the news APIs and how to use them available here:
http://java.sun.com/j2se/1.4/articles.html [sun.com]

Coincidence?

I find it funny that the post mentions a lawsuit from Kodak and the O'Reilly essay about Java says:

[...] At the same time,

Sun loves to have Kodak moments with some parts of the open source community -- most notably, Apache -- who increasingly feel used and abused [...]

(Emphasis mine) Heh.

Asserts

This makes me so happy. Coming from C++, I really really missed assertions. They give me much more confidence in my code. Some people seem to have trouble using them, but after a while they can become second nature. In fact, one can come to rely very heavily on them.

J2EE openness

Well that kind of gives an answer to every javahead that says "Why bother with Mono, when you have J2EE? What a waste of time."

Mono is at least opensource... can you say the same for J2EE? Will you ever be able to say the same?

Re:J2EE openness

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.

Wording was bad

The story should have read "no LICENSED open source J2EE implementations". There are OS J2EE app servers (JBoss), and in fact they are quite good... the problem (as stated in the article) is that it's hella expensive to get the official seal of J2EE. That doesn't mean it doesn't work!

Now if you think .NET is better, you have to ask how good an open .NET server you're going to be able to build without ASP.NET or Windows Forms. Neither of those are part of the current ECMA submissions, though as stated in the .NET article yesterday they are expected to be submitted at some point...

At the moment J2EE has gone through a lot of refinement, and I think makes a pretty good platform for server side development. I think desktop code is still up for grabs by either Jvaa or .NET (at least under windows). It will be interesting to see if .NET app development is nearly as annoying as MFC was (I doubt it will be).

Genericity?

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

Re:Genericity?

1.5 [javaworld.com]

64 bit - wow!

The 4 GB address space limit has become a severe limit on Java bloat. It's good to see that Sun finally addresses this problem.

J2SDK on Win98 and Linux

I have a dual boot machine at home, one partition Windows 98, the other Slackware 8.0. Today I downloaded and installed the new Java SDK 1.4.0-rc on both systems. And while I think that some iscolated windows difficulties causes my oppinion to be rather biased, I found the install much easier going on Linux.

However I will note that, while the Java Web Start was installed on Windows, I didn't find any version of it for linux. And the downside to the Web Start I found is that it constantly wanted to download and install a new version of Java Runtime Environment 1.3.x everytime I lauched an application. And then after the download, and installed, I'm prompted to reboot the computer. After rebooting and trying to launch again, it again starts to download JRE 1.3.x and through the whole cycle all over again.

As well, with my windows install I found I was constantly having difficulties getting it to use the default classpath (ie, no environment variable set for CLASSPATH). I ended up having to resort to specifying the classpath at the command line. And no matter how much I tried, I could no manage to get Swing to work properly.

However on the other hand, the Linux install was rather straight forward, with a few simple steps: Change download to executable; Run it; move the extracted directory to a shared path (as su); add the java/bin directory to the search path; and finally add the java/man directory to the search paths for man.

The windows installer was straight forward, though the above problems still hampered me.

Re:J2SDK on Win98 and Linux

No, all is unlikely to be hunky-dory if you set the classpath environment variable. This seems to cause more problems than anything else to newcomers. It's much easier to avoid using a classpath environment variable in the first place - the default is fine for most things, and the extensions mechanism really helps. I've got short essays about both on the Java bit [pobox.com] of my site.

Jon

I've been using this for a while

Autopr0n.com actualy runs using the first beta of JDK1.4. I needed the new ImageIO libraries for the, um, 'site previewer :P' (and the regexs made some of the parsing I'm doing a lot easier :). I tried 1.4b3 but it was far more unstable, and my regexs broke.

Definetly cool that the stable version is out, I'll have to upgrade at some point, when I have time.

Hopefully they'll implement this at Topcoder.com too, so I don't have to keep using the old docs in the compos :P

At least Sun is brutally honest.

Jesus, Sun's PR corps must have flipped their collective shit when they read Karen Tegan's remark [oreillynet.com]. While in general I find that kind of bluntness refreshing, a director of Platform Compatibility spouting off and essentially saying, "Well, that sucks for you, but we make money off of compatibility testing. We give everything else away for free, so cut us a break." is really a testament to the Sun Micro (brutally) plain-talking attitude.

Deeper, though, I think, is the need to rein in Java a bit....It has achieved ubiquitousness, and I think Sun knows it. Watch. If .NET takes off, they will loosen up to benefit from a little more old-fashioned agrarian innovation and buzz.

My take on JDK 1.4

OK.. I am a Java fan... (recently this has been changing though.)

I have mixed feelings with JDK 1.4.

The JPDA (debugging) support in 1.4 is vastly improved. You can now redefine [sun.com] classes in a running virtual machine. This is really cool and I have written an Ant 'Redefine task to take advantage of this.

The assert facility is OK.... i don't like the fact that they added an Assert keyword but I don't get to make the decisions.

There is also some controversy.

The JSPA agreement that one has to sign to participate in the JCP [jcp.org] is WAY too restrictive for Open Source developers. The Apache Software Foundation has a good document where they drawn the line in the sand [apache.org] on their participation.

The Log4J people are upset because there is now a 'stanard' Java package for logging. IMO the 'standard' package is inferior to Log4J in many situations.

The regexp package is not all it is cracked up to be either. I would recommend Jakarta ORO or Jakarta Regexp.

As far as that... it runs GREAT on Linux. Probably the most SOLID VM I have ever run.

They did break some stuff with legacy code. If you ever named a class 'URI' your code will now fail to compile because they put this class in the java.net package which everyone imports anyway.

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.

Also.. check out my Reptile project. [openprivacy.org] It is Java based, only requires JDK 1.2 and incorporates some really cool Java/XML stuff. :)

Re:My take on JDK 1.4

They did break some stuff with legacy code. If you ever named a class 'URI' your code will now fail to compile because they put this class in the java.net package which everyone imports anyway.

Not really a 'breakage'. If you imported only what you needed (java.net.URL, java.net.Socket etc.) your code will continue to work. Only if you used the statement "import java.net.*" will it now fail, and that's down to the individual coder, not the JDK.

Cheers,
Ian

Re:My take on JDK 1.4

They did break some stuff with legacy code. If you ever named a class 'URI' your code will now fail to compile because they put this class in the java.net package which everyone imports anyway.

If you have a foo.bar.URI class, and the core has a java.net.URI class, you can still use yours.

You can:

1. specifically name the package at the usage (messy),
2. specifically include only the java.net classes you want, one by one, rather than including java.net.* (inconvenient),
3. or just clarify which URI class should be used in the imports specifically:
   • import foo.bar.*;
     import java.net.*;
     import foo.bar.URI; /* hides java.net.URI */

Existing code does not need to be recompiled, since bytecode always explicitly names classes always, but existing code does potentially need to be fixed if recompiled, as the default results of the imports will change. This is a pretty small and common occurrence with a new API set.

Re:My take on JDK 1.4

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.

Good articles

Are there some good articles out there (besides the sun ones) on how to use the new features?
thx
matt

Open Source Java VM & class libraries

Are there any _good_ java VMs and class libraries? Kaffe looked decent, but appears to be a little "stale" wrt the current state of the art. Are there any projects working to address this?

Re:Open Source Java VM & class libraries

Look at the bottom of the classpath [classpath.org] page for a list of open source VMs that work with classpath (a free core (i.e., java.* and a few others) class library). All works in progress. I expect that mono and/or portable.net will quickly outpace free java projects. The JDK is a case where the availability of good enough gratis software has seriously hampered the momentum of libre competition. Netscape 4.x is another such case.

Kodak invented OLE?

I just took a look at the three patents Kodak is suing Sun over, and, huh?

Sure looks like Kodak claims it invented OLE.

Which, hey, they may have, and Microsoft either licensed or stole it.

What's the real story?

--Blair

Re:Kodak invented OLE?

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.

My pet peeve.

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.

Security export rules

As usual the "import control restrictions" once again are in full force. From the release notes:

Due to import control restrictions, the JCE jurisdiction policy files shipped with the Java 2 SDK, v 1.4 allow "strong" but limited cryptography to be used. An "unlimited" version of these files indicating no restrictions on cryptographic strengths is available.

The JSSE implementation provided in this release includes strong cipher suites. However, due to U.S. export control restrictions, this release does not allow alternate "pluggable" SSL/TLS implementations to be used

What seems even stranger now is that you cannot used "pluggable" implementations (in JSSE). Maybe the "nasty" europeans/asians/africans/martians would provide some unlimited strong cryptography pluggin otherwise???

Re:Security export rules

There is already a clean room, open source (BSD License) implementation of the JCE. It's called Cryptix [cryptix.org], and simply put is one of the best libraries ever written for Java.

I don't trust black box cryptography... especially when Sun goes the extra mile to obfuscate their default implementation of the JCE crypto modules.

Patent titles

The article says nothing about the nature of
the supposedly infringed patents. Here's their
titles:

US05206951
Integration of data between typed objects by mutual, direct invocation between object managers corresponding to object types

US05421012
Multitasking computer system for integrating the operation of different application programs which manipulate data objects of different types

US05226161
Integration of data between typed data structures by mutual direct invocation between data managers corresponding to data types

new in 1.4: public Exception(Throwable cause)

My favorite thing about using 1.4 is code like this:

public void methodA throws MyException {
try { Driver d = Class.forName(driverClass).newInstance(); }
catch (Exception ex) { throw new RuntimeException("problem loading driver"); }
}

can now be this:

public void methodA throws MyException {
try { Driver d = Class.forName(driverClass).newInstance(); }
catch (Exception ex) { throw new RuntimeException("problem loading driver", ex); }
}

Notice the RuntimeException constructor now has the original exception passed to it. It can be retreived higher up the stack, and I believe is printed during a ex.printStackTrace(...). It lets you pass the root cause exception up the stack trace, while preserving the entire state, without having to declare it everywhere.

Anyone here read the license?

5. Notice of Automatic Software Updates from Sun. You acknowledge that the Software may automatically download, install, and execute applets, applications, software extensions, and updated versions of the Software from Sun ("Software Updates"), which may require you to accept updated terms and conditions for installation. If additional terms and conditions are not presented on installation, the Software Updates will be considered part of the Software and subject to the terms and conditions of the Agreement.

6. Notice of Automatic Downloads. You acknowledge that, by your use of the Software and/or by requesting services that require use of the Software, the Software may automatically download, install, and execute software applications from sources other than Sun ("Other Software"). Sun makes no representations of a relationship of any kind to licensors of Other Software. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE OTHER SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Open Source J2EE

I thought http://www.jboss.org/ and http://www.exolab.org/ were getting pretty close to open souece J2EE?

(BTW yes j2se 1.4 does mean scrolling in Netbeans without any plugins).

Why is this not under the developers section?

Why is this not under the developers section?

My pet hates with Java

• Unicode support is broken. Java's 'char' type is supposed to represent unicode characters. However it is only two bytes wide so does not support codepoints beyond U+FFFF, such as various Chinese characters. String handling is built around the assumption that UTF-16 has one character per byte-pair, so String.length() can give incorrect answers, String.substring() can give invalid UTF-16, etc. (This fault applies to C# and .NET too, AFAICT)
• Because Java contains a lot of special-casing for String objects (such as overloading '+' and forcing a toString() method in every class), and because String is final, you can't write your own class BetterString which fixes this unicode problem and still works like a String.
• There is no universal type like void* in C. There is Object, but primitive types (int, char, float, etc.) are not objects. You can't pass them by reference. There are duplicate, object wrappers for these (called Integer, Character, etc.) which can be passed by reference, but you spend stupid amounts of time wrapping and unwrapping primitives.
• A function cannot take variable arguments of arbitrary type. The closest you can get is a function which accepts an array of Objects. (But Object is not a universal type - you can't give primitives to such a function without wrapping them).
• You can't create a list anonymously. if x, y and z are ints, and "average" is a function which takes an array of ints, you can't do "average({x,y,z})". This makes the previous limitation more serious.
• Things that should be warnings are in fact errors. For example, this snippet won't compile, because "a might not have been initialized": int a;int b = 0;if(b == 0) {a = 1;} System.out.println(a);. There are times when you want to write code logically equivalent to this, but the compiler makes you pointlessly initialise the variable at the start. The programmer may know things that the compiler doesn't; in this instance, that a will be initialised. It would be better for the compiler to merely warn, and then a runtime error to occur if the programmer was wrong.
• The syntax is intentionally inflexible. To add a worthwhile "assert" statement, Sun had to add it to the core language, which is something that only Sun can do. Compare C, where anyone can write a reasonable assert macro. The same thing will apply to other things which you might want to do, but can't.

Oh yes, and I nearly forgot a trivial-but-annoying one:

• byte is signed in Java - instead of running from 0 to 255, it runs from -128 to 127. If you want to write the byte 0xA9 ( = 169) to a binary file, you have to call it -31.

Re:My pet hates with Java

I fail to see how a declaration "String str = null" is any safer than a declaration "String str".

You've used this serveral times as an example. You're right, assigning a string to null is not safer than leaving it uninitialized. However, that just gets around the 'uninitialized variable' error from the compiler. You should initialize it with something meaningful, or at least "". That would be more safe, and would be what the compiler wants you to do. This error has saved my butt more times than I care to remember, so don't knock it.
If you want to use variable arguments, pass in a vector or a list. There are ways to make java do what you want to do, they might not be like those in C or C++.

Headless at last - bye bye XVfb

My favourite new feature is that lightweight components can now be run in headless mode - see

http://java.sun.com/j2se/1.4/docs/guide/awt/AWTC ha nges.html#headless

You have to set a property to true:

-Djava.awt.headless=true

as a switch when running the VM for example. Then you can generate server-side graphics on Unix without having to run XVfb. This has been an annoyance for some time, as you had to have different deployment rules depending on your target OS, as NT always has a graphical environment taking up resources whether you want it or not, so it wasn't an issue there.

The upshot is that you can now use java.awt.Image.BufferedImage as an image source in servlets that generate dynamic images, instead of java.awt.Frame, which always seemed wrong. It uses less resources too, as it doesn't have to do a context-switch to your X server to create images!
Hey, there are lots of great new features in this new release, but that is the first one that made life easier for me.

Why I Don't Want to Touch This

I use Java at work and I had to beat 5 fucking team leads with a crow-bar to convince them to move to Java 1.2. Now they all run the other way when they see me coming -- it's a lot harder to get near them with a crow-bar. By the time my company gets done with its final focus meeting to decide that moving to 1.4's a good idea, Sun will be releasing Java 2.4 (With telepathic user interface code.) If I get all used to how great Java 1.4 is, work will suck more, and it already sucks so much that light can't escape.

New I/O

The New I/O utility looks interesting -- possibly powerful enough to overcome the problem preventing me from using Java right now: 16-bit characters.

Yes, 16-bit characters are nice for internationalization, but if I'm trying to slurp up 600 MB of data, it really hurts to have to store the text portions using two bytes per character. I know it's not politically correct, but perhaps a choice of char sizes would have been nice? (I'm a Java newbie, though -- there's probably an esoteric way around it.)

Cyrix and 1.3

1.3 completely broke Java on Cyrix. Once you installed 1.3 you were SOL - every time a VM started, you'd get an illegal instruction error. Sun used an optional P6 instruction that Cyrix chose not to implement to keep power consumption down. Instead of checking CPUID to see if the instruction was available, they just checked the processor familly and assumed that the instructioon was there. Intel's docs clearly state that the instruction is completely optional and that apps should check a flag returned from CPUID before using it.

Sun has known about this for over a year now, but they refused to fix it. Hopefully 1.4 will actually run on by Cyrix box now.

Still didn't fix it...

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

The new Mozilla plugin...

...finally works with the old banking applet I'm forced to use. Cheers!

Still no GUI fixes?

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

time to freeze the platform!

I will probably get a few flames for this:

I enjoy developing with Java, but for the last year or two I have increasing felt that the time is appropriate to freeze the platform except for bug fixes.

A similar situation existed a few decades ago in the Lisp world: there were many great dialects of Lisp and a large committee effort stirred everything together as ANSI Common LISP. Is Common LISP perfect? Of course not, but it is a very stable platform supported by both free Open SOurce implementations and several very good commercial products.

I would like to see Sun slow down the marketing-driven new releases.

I think that the Java community would now be best served by a stable frozen platform.

Anyway, just my opinion :-)

-Mark

native freebsd?

where is it?

i remember reading
http://slashdot.org/article.pl?sid=01/12/23/0314 25 7&mode=thread&tid=122

http://daily.daemonnews.org/view_story.php3?stor y_ id=2602

yeah whatever?

unrelated - javahelp problem

I just started rolling out a javahelp application on my 'doze boxes, only to find that hsviewer crashes. These are fully patched W2K boxes, and trawling the web produces no mention of hsviewer.exe exploding in on itself. Suggestions ? (apologies for the offtopic post - my monday deadline prompted it).

Bugs

JDK1.4 has alot of features, but the biggest improvments is BUGS! The Java group spent 6 months doing nothing but fixing bugs. We went from 60 bugs in the Server compiler down to 0. JDK1.4 is much more stable the previous releases

How long before IBM has their 1.4 JVM out?

IBM's 1.3 series of JVM's are faster, more stable and better supported than the line series. How long are we going to have to wait until IBM releases their version. IBM have been throwing their weight around recently with Java (& Linux). Lets see if they are willing to keep up that so called support.

J2EE Certification

I'm a big fan of JBOSS, and (though I haven't tried it) would've liked to see Enhydra succeed as open source. But I don't see why Sun should grant a J2EE trademark to them. Sure, the price might have been outrageous, but companies like IBM and and BEA seem willing to pay it. Sun allowed them to see the source from the reference implementation and allows them to use the parts of it that haven't been implemented independently yet.

The spirit of open source isn't about marketing. And the J2EE mark is just that. JBOSS is very successful on its own right, and whether Sun blesses it shouldn't matter. Apache has succeeded without Netscape or Microsoft's compatibility certification, though there are still companies who feel more comfortable with a web server branded by a large corporation. Though this draws comparison with Versign refusing to recognize certificates from Apache, its not quite as bad, and eventually, they were forced to accept. Anyway, verisign isn't exactly to be held up as a model corporate citizen

It might be desirable for Sun to open up java to public standardization, but I don't think anyone build on java expecting that to happen. Its like WINE expecting Microsoft to certify it as 100% Windows compatible (even if it really were.)

It may be one day that people will want their J2EE implementations to be JBoss compatible.

Practical Experience from the Field

Two thumb up on JDK1.4. The new io (nio) alone is worth the switch. I've been playing with it since beta one, and except for a strange bug (now fixed) in UDP where all incoming packets on all channels each falsely reported their origination address as having come from the same address as was reprorted on the first packet... except for that!:)... this stuff rocks. Packet transmission speeds are up something like 40-50% or more if I recall correctly. It's quick.

The Channel abstraction for talking to sockets also happens to be a nice one. The whole nio library has the taste of having been well-thought out by someone who really new what he was doing.

C//

SUN dismiss valid bugs

Try the following snippet out on jdk 1.3.1 and 1.4.

public class JDK14Bug {
public static void main(String[] args) {
java.rmi.server.RemoteServer.setLog(null);
}
}

The javadoc says "Log RMI calls to the output stream out. If out is null, call logging is turned off."

To me 1.4 is broken. If I pass in a null I now get a NullPointerException with 1.4.

So I raised a bug on the java.sun.com site. A couple of weeks ago I get an email telling me it is a duplicate of another bug (which it isn't!). I was also told this is now the expected behaviour. It clearly doesn't follow the javadoc and has broken existing behaviour. I asked for Sun to look again but alas no reply.

What gives!

Re:How about a massively parallel

Its about time for the lameness filter to kill any reference to a "beaowolf clsuter of "

talk about a joke getting old!!

Re:Java2 ?

Hmm, if SDK v1.2 became "Java2", shouldn't v1.4 be called "Java4"? Oh I see, "Java2" was a "marketing trick" used in the tough year 1997 and the name has stuck.

Perhaps,but remember that the change from 1.1 to 1.2 contained some major rehaul of APIs.

In this 1.4 release Sun kept a carefully budgeted set of new features and emphasized quality and performance, like they said they would. You can expect more changes in 1.5 (codename Tiger) which is planned to come some time around the middle of 2003. If that will be Java3, who knows, they have just started working on it.

Re:It's a Release Candidate

No, it's the real release. It doesn't say Release Candidate anymore. It has been RC for a while but now it's for real. I call this news.

Re:Not meaning to troll but....

If I had mod points, I would give them all to you.

Yes java is the most overrated language next to esperanto only.

Re:Not meaning to troll but....

What good is this platform really?...It seems to me that Java is nothing but slower than other languages

The platform is not the language.

Java is good partly because of its pragmatic syntax (C++ish with some sugar added, some sugar taken away), but mostly it's good because of its excellent class library.

Though I haven't written anything serious for a year or so due to a job switch, I used to write large-scale multithreaded network servers, where somthing like three to four hundred threads could be running at any given moment inside the server. Java's class library made this really quite easy, and it's syntax is pleasant enough to work with.

Cheers,
Ian

Ironic/NBIO

I used to write large-scale multithreaded network servers, where somthing like three to four hundred threads could be running at any given moment inside the server. Java's class library made this really quite easy, and it's syntax is pleasant enough to work with.

It's kinda ironic that you should say this, since threads are the wrong [usenix.org] way [berkeley.edu] to write "large-scale" network servers, and since Java 1.4 finally gives us non-blocking IO APIs [sun.com] to implement things the right way. (The NBIO APIs in 1.4 are, incidentally, largely a product of the work of the fellow behind the second link I gave.)

Re:SLASHDOT BIAS

"facade of neutrality"?

Do you even read Slashdot? :)

I don't think anyone claims this is an unbiased news site. It's a message board for Linux geeks. Love it or leave it. Or present your own viewpoint. :)

Re:skeptical for the desktop

Sun is like Microsoft - they make as many features as possible, worry about the bugs later and let hardware catch up to overcome their crippling defects caused by overzealous and misinformed OOD.

Okay, I can't take this any more - Java is not slow or buggy and can produce applications that are indistinguishable from C/C++ applications. The proof of this is simple - rewind the clock back a year to MacWorld where WorldBook Encyclopedia [apple.com] was demoed as part of the keynote with everyone watching and they were all impressed. Months later I was informed by the "head Java dude" at Apple on his Australian tour that WorldBook is completely written in Java - but noone knew.

Most people think that Java is slow, buggy and doesn't look platform native because they assume that anything that is fast, stable and looks and feels platform native wasn't written in Java. It's even cooler though, because the "write once, run everywhere" of Java actually works if you write good code). Sure there are some things that Java can't do that you need native code modules to handle but that facility is available.

The worst thing is that young programmers are led to think that Sun's code is actually *good* which spreads their poor, inefficient form to the next generations.

Java's not perfect, but I seriously don't think that it's Java that corrupts young programmers. You can write good code in almost any language - I see an awful lot of really bad Java code written by C programmers but I'm not about to claim that C is corrupting old programmers.

Re:Java2 ?

Remember, this is Sun the people who released Solaris 2.0 which:
- was the first version of Solaris
- declared itself to be SunOS 5.0
- was an implementation of System V Release 4.0

Obviously being able to count is not a prerequisite for getting a job in Sun's marketing department.

Re:Hmm, Sun is up to no good again

Unix version contains software licensed from Mainsoft Corporation. Copyright (c) 1998-1999 Mainsoft Corporation. All rights reserved. Mainsoft is a trademark of Mainsoft Corporation

That's worrying. Mainsoft's only product is MainWin, a library for emulating Windows API on Unix (similar to the library version of Wine).

Why is Java rely on emulated Windows code?

Re:It's a Release Candidate

Okay, I expected someone would mod parent post down and went to download and install the **1.4.0 final release**...

Of course, no problem with the install and I made sure I didn't get the Release Candidate.

Now what? Insightful mod and AC ranting?? Maybe you guys should hit the refresh button harder!

Re:skeptical for the desktop

Sun are putting the desktop on the back burner.

Yeah, that must be the reason they

• Include a very useful Preferences API that only has relevance for - you guessed it - desktop applications and possibly applets
• Are still pushing JNLP and their implementation of it (Java Webstart)
• Constantly improve the AWT and Swing libraries
• Ship the plugin as standard part of the JRE, and the HTML converter as a standard part of the JDK
• Integrate directly with Internet Explorer to handle APPLET tags (since JRE 1.3.1_01a)

  I am sure there are other examples, too.

  Are you absolutely sure you have checked out the 1.4 release at all?