Java2 SDK v. 1.4 Released 362
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.
Summary of new features (Score:4, Informative)
http://java.sun.com/j2se/1.4/docs/relnotes/featur
Articles about the news APIs and how to use them available here:
http://java.sun.com/j2se/1.4/articles.html [sun.com]
Asserts (Score:3, Informative)
Re:Java2 ? (Score:4, Informative)
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.
To lazy to write it yourself? (Score:3, Informative)
AUTOEXEC.BAT (Score:3, Informative)
Security export rules (Score:4, Informative)
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:My take on JDK 1.4 (Score:4, Informative)
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
Patent titles (Score:5, Informative)
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
Re:It's a big step up, but there is still distance (Score:4, Informative)
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
Java Secure Socket Extension (Score:5, Informative)
???
new in 1.4: public Exception(Throwable cause) (Score:4, Informative)
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.
Re:Open Source Java VM & class libraries (Score:5, Informative)
Re:Genericity? (Score:4, Informative)
Anyone here read the license? (Score:3, Informative)
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.
Ironic/NBIO (Score:5, Informative)
Re:hope swing is faster now / I prefer Ruby over J (Score:1, Informative)
8-10 times faster on a remote X session.
Re:J2EE openness (Score:1, Informative)
www.jboss.org
Re:My take on JDK 1.4 (Score:5, Informative)
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:
import java.net.*;
import foo.bar.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:skeptical for the desktop (Score:5, Informative)
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:Good articles (Score:2, Informative)
My pet hates with Java (Score:2, Informative)
Oh yes, and I nearly forgot a trivial-but-annoying one:
Re:My pet peeve. (Score:2, Informative)
"We've attempted to resolve this with Sun for about three years, but the discussions with Sun have not led to a suitable licensing agreement," Kodak spokesman Anthony Sanzio said.
It looks more like Kodak is suing them because they couldn't work it out in another way.
Whether the patents are valid or not is a different issue...
Bullshit (Score:1, Informative)
Specifically for this posting, I can't comment on the Unicode stuff, but:
* Wrappers work OK. They allow good performance for the primatives without the many problems void* can cause. The wrappers are hardly difficult to use and in fact they're used pretty infrequently.
* Variable arguments to functions: Java is not C. Get over it. Not every feature of C is worth cluttering up the language for. The number of times I've needed varargs in my life is
* You can't create a list anonymously: What about average(new int[] { x, y, z }) ?
* The syntax is intentionally inflexible: Sun added assert even though many people didn't like it. Here's an assert class:
public Class Assert {
public static void assert(boolean assertion) {
if (!assertion)
throw new RuntimeException("blah");
}
}
You can put Assert.assert(boolean) anywhere and it will throw a runtime exception on failure.
This stuff is not rocket science, but hardly anyone posting to these threads seems to have a clue about Java. Java has it's flaws but IMO they are far less serious than C or C++ for writing large applications.
Re:My pet hates with Java (Score:1, Informative)
Just go write your C programs and quit complaining why Java isn't more like C.
Headless at last - bye bye XVfb (Score:5, Informative)
http://java.sun.com/j2se/1.4/docs/guide/awt/AWT
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.
Re:Security export rules (Score:5, Informative)
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.
Re:My pet hates with Java (Score:5, Informative)
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++.
Re:My pet hates with Java (Score:2, Informative)
I guess it's pointless to argue with trolls, but:
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.
So you didn't know that the Unicode standard [unicode.org] quite explicitly states that "Unicode character values are 16 bit"? Hence, no "codepoints" beyond U+FFFF exist!
You can't pass them by reference.
I have seen exactly one method that is dragged out as example of why you need to pass primitives by reference, and that's swap(a,b), which is just of academic interest.
A function cannot take variable arguments of arbitrary type.
Then use Object[]. "Variable arguments of arbitrary type" is a hack that works in C because C isn't properly strongly-typed, and has no place in Java.
You can't create a list anonymously.
As others have pointed out: Yes, you have been able to since JRE 1.1 (prior to that, only in declarations).
The syntax is intentionally inflexible. [...] Compare C, where anyone can write a reasonable assert macro.
Gee, how "standard" that sounds, so now I have to learn some nincompoop's particular fancy if I take over their code. Macros suck anyway because they ignore the type system, and most C++ literature I've seen wisely discourages their use.
As for flexibility, are you opposed to standards? Then stop using C because its syntax is also "inflexibly" specified in a specification.
byte is signed in Java
All numeric values except the special-purpose char are consistently signed. No need to go and check every time you use a numeric variable. This is a good thing.
assert keyword was the right decision (Score:3, Informative)
Dude, read up. There is an excellent discussion [sun.com] of the reasoning behind their design decisions. They give a very good justification for adding a keyword; in fact, it's one of the FAQ questions:
Unlike a lot of other languages (C++ and C# spring to mind), the Java designers have been very tight about letting multitudes of constructs into the language. Java's minimality and internal consistency is one of the reasons it's been so successful, and its designers know this. They are very intelligent people who are making decisions very carefully -- and they're not going to add something to the language unless they have a very good reason.
In this case, they have a very good reason.
Re:My take on JDK 1.4 (Score:3, Informative)
Stuff like logging APIs have enormous added value if everyone uses the same logging mechanism. Applications using multiple libraries that use disparate logging mechanisms are a mess. The result is people create kludges to integrate all of the various logging techniques so that they output to a single place. Sun's rejection of log4j will result in this happening.
Log4j is really better than Sun's. Oh well.
And nobody is upset that Sun didn't clone log4j. Everyone is upset because Sun didn't *take* log4j lock-stock-and-barrell. Apache/IBM offered it for the taking. The result is Not Good.
Have you ever used java?!? (Score:1, Informative)
Java chars are 4 bytes long, just like java integers. Maybe you're thinking of shorts?
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.
Ever heard of security? Stability? Do you know what immutable objects are? Can you imagine the havok that would insue of Strings could change their values arbitrarily after creation time? If you didn't answer yes to all three, shut up.
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.
The only time this is ever at all a bad thing is when you try to put primitives into collections that take objects. Hopefully the plans for generic collections will allow you to move the two lines of code that convert the primitives to objects and back will be replaced by a more interesting two lines of code somewhere else.
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).
Just suppose you could find a genuinly good use for a function that needs variable arguments of unpredictable type -- and object array is as good as anything. Just wrap any primitives and declare the array right where you need it (although you don't appear to know that such a thing is possible -- see next response).
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.
RTFM. Try average(new int[]{x, y, z}).
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.
Java warnings are, quite honestly, the best thing since sliced bread. I watch people trying to write C++ programs who regularly forget to initialize variables and spend hours trying to figure out what's going wrong. Java 1.4 is getting even stricter with the rules for acceptable code, which means that more programmers will have to fully understand the implications of what they've written. This is a Good Thing (TM).
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.
Have you ever seen an obfuscated java contest? I rest my case.
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
Every primitive number type is signed in java. That means number types are few and consistant. No warnings (not that these warnings are bad) about implicit casts between signed shorts and unsigned longs. If you must hold a number between 0 and 255 directly in a primitive, use the int type. It you want to complain that the int type will hold numbers that are too big, just & off all of the bits you don't want before you display the final number or whatever.
Re:My take on JDK 1.4 (Score:3, Informative)
Sorry to hear that, I hope I can persuade you a bit back towards the good side of the force... ;-)
I have mixed feelings with JDK 1.4.
I'm mostly ecstatic about it. =)
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.
I wish they had done a better job of support DBC, but it should still be useful. I'm not too sure what it bought over just using existing "assert" hacks, which can also be compiled completely out.
There is also some controversy.
Perhaps in the minds of some...
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.
I'm not sure what the complaint is here. If Log4J is superior (I've not looked at the logging API yet), it should still attract lots of users. Regardless, there is no way for Sun to extend the core JDK without potentially stepping on the toes of some developers. I don't see an easy way around that problem.
The regexp package is not all it is cracked up to be either. I would recommend Jakarta ORO or Jakarta Regexp.
Again, I can't comment on the technical merits of one versus the other. However, again I'm not sure what your problem is. There are alternative packages, which are better. Great, then use them! The core packages are essentially developed by committee, and are only one approach to the given problem domain. There are many tradeoffs in library design...
As far as that... it runs GREAT on Linux. Probably the most SOLID VM I have ever run.
That sounds great! I'm just about to install it.
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.
That is not "breaking something". That is the reason Java has namespaces. Not a big deal at all.
As far as C# vs .Java. I am really impressed with the CLR/CLI stuff.
I'm not sure why...care to clarify? Have you read the comments about CLR based languages all being different skins of C#?
I'm also not sure why people seem to feel it's impossible to interface Java to legacy languages. People do it all the time using JNI.
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.
Sun has made noises about open sourcing Java at some point. If it'd just release the compatibility tests as open source, that would go a long way. (It is currently perfectly fine to 'clean room' Java, as gcj is doing. You just can't call it "Java" without essentially licensing Java and getting the compatibility tests.)
Regardless of Sun's timing in releasing Java as open source, you're completely out of your mind if you think interest in Java is going to significantly lessen because of the introduction of C#/CLR. C# and the CLR are both fledgling technologies, where Java is quite proven and robust. I just read about the first CLR security exploit, and I expect many, many more. Heard of any with JVMs lately?
C# and the CLR only run on small computers and operating systems compared with the high availability big iron that runs Java. Also, Java has penetrated small devices very effectively, with over 100 million Java enabled cell phones to ship this year, very significant embedded penetration, and instruction set support for Java bytecode in all the new generation of ARM chips such as Xscale. Microsoft is caught in the middle (granted the middle covers a lot of ground;).
Despite all the rhetoric to the contrary, I advise you to expect big things from Java on the desktop as well. Sun is quietly staying the course, and is making big improvements to client side Java with every release. Since Java supports Windows, MacOS and Linux, it is a very attractive way to deploy applications (we'll see when C# achieves this milestone;). Earlier releases coupled with slower computers were painful, but things have improved to the point where Java is perfectly usable for lots of applications. Linux + Java is a potential Microsoft killer, make no mistake about it and Microsoft knows it.
My final point for today regarding the "open" nature of C# and the CLR is that quite a lot of the C# class libraries available under MS Visual Studio are not included in the standard. This includes the GUI libraries, so as things stand you can use Java today to write completely cross-platform GUI based programs. It will most likely be a cold day in hell before Winforms are available anywhere but Windows. I'm betting Microsoft's legal team will make sure of it. We'll see if Mono gets far enough to be a test case.
Sigh, now the long wait begins for JDK 1.5. ;-)
(Reptile looks cool, I'll check it out later.)
299,792,458 m/s...not just a good idea, its the law!
Re:Yah, will this be stable on Linux? (Score:2, Informative)
You should only complain about linux kernel being unstable when you run a vanilla 2.4 kernel. pktcdvd.c is not part of the standard kernel, it's part of Jens Axboe's packetised cdr writing patch - which is alpha quality. That patch is not even in 2.5.5-pre1 so you can't really blame linux - only the buggy patched version you have running!