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.
It's a big step up, but there is still distance (Score:4, Interesting)
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.
J2EE openness (Score:2, Interesting)
Mono is at least opensource... can you say the same for J2EE? Will you ever be able to say the same?
J2SDK on Win98 and Linux (Score:3, Interesting)
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.
I've been using this for a while (Score:3, Interesting)
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
At least Sun is brutally honest. (Score:3, Interesting)
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
My take on JDK 1.4 (Score:4, Interesting)
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
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.
Good articles (Score:2, Interesting)
thx
matt
Kodak invented OLE? (Score:3, Interesting)
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:Not meaning to troll but.... (Score:5, Interesting)
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
Re:Genericity? (Score:2, Interesting)
Jon
Re:J2SDK on Win98 and Linux (Score:4, Interesting)
Jon
Re:Asserts (Score:3, Interesting)
They are easy; they catch bugs that might not otherwise ever be noticed (or noticed only as some pervasive flakiness); they save you a lot of time that would otherwise be spent debuging; they are good documentation; they don't cost anything in non-debug builds; they save you from a lot of pain. Despite all this, I haven't yet successfully convinced a single person who is unfamiliar with them of their value. Christ I get dismayed sometimes.
This interview [kerneltrap.com] with FreeBSD kernel hacker Matt Dillon has some interesting things to say about assertions ("it greatly contributed to our famed stability in 4.0 and later releases [of the FreeBSD kernel]").
Java finally has them? Cool. What year is it again? 2002? Jeez
Re:Genericity? (Score:2, Interesting)
Bracha pointed out that one problem with C++ templates is code bloat. For every List<T> of type T, C++ generates a separate class.
I'm glad someone posted this link. This is EXACTLY the problem with C++. It isn't in the class structures (they are almost exact to C's structs) but the fact that the templates have to generate seperate class structures to make sure that each one doesn't conflict.
This I have seen working with C++: A matter of a template has done almost a 25% - 80% reduction in my executable size. I'm not kidding -- from 1 MB to 200 kB! This was the case because I made two instances of the same class (cut 'n paste) because I really didn't need all the generics involved in the program. While typing all that stuff then doing a cut-n-paste was slow to do, the executable size was worth it.
Anyway, if you code in C++, the STL is decent FWIW. I wouldn't lean on it though if you're going to do major embedded coding... but get the String class; it's great.
skeptical for the desktop (Score:0, Interesting)
Re:hope swing is faster now / I prefer Ruby over J (Score:2, Interesting)
Re:Genericity? (Score:3, Interesting)
The 1.5 Java generics are merely syntactic sugar. Since the casts still occur, there is no performance benefit, only cleaner source code. There is no way to parameterize primitive types like int.
I do not consider the proposed generics to be adequate. You are still better off, performance wise, generating your own custom collections for specific types. This is what GNU trove does.
-Kevin
You agree to all future licence agreements. (Score:2, Interesting)
This means that they are claiming that if you agree to this licence, you are also agreeing to the licence of any application which installs itself (and you have agreed to let it install itself).
I'm sure that that is not legal, and could invalidate the whole agreement. On the other hand, I don't see how a licence agreement that you haven't signed is worth the pixels its printed on.
To say that Sun's online license agreements are binding would be to say that you are not allowed to click on a button with two words on it which is displayed on the web without agreeing to this contract.
As someone pointed out in response to another article, not agreeing to the licence agreement preserves your right to click on the "I Agree" button without agreeing to the licence agreement. It is in the agreement that it says that you agree that clicking the button means that you agree.
Is that convoluted enough?
Re:skeptical for the desktop (Score:3, Interesting)
I find the example set by WorldBook 2002/MacOSX to be a stunning demonstration of Java's potential if Sun would just wake up and smell the coffee (pun intended).
I like Java a lot - both as a language, and as a bytecode platform. I use it daily at work, and at home for my own projects (after many years of flipping between C, C++, and a dozen other niche languages)
My only major bugbear with the JDK is not with Java itself, but with Swing: It's godawful slow (The Hello world app should not take 30 seconds to display on a P400), it's API is occasionally appalling (JTree anyone?), and it has a habit of being occasionally buggy.
Above all, it reinvents the wheel with widgets. The Look and Feel implementation very occasionally looks and feels like a platform native application (Win2k LnF anyone?). However, it usually looks and feels like someone has tried to reimplement a system native toolkit using only a blunt light blue crayon.
For many a year I have whined to all that would listen "Why the *@*)(!&*@ doesn't the Java widgeting toolkit defer to system native widgets for window display? Surely this would look better and run faster than pixel blitting a widget look-a-like!"
MacOSX provides just such an API. Although Objective-C is the `preferred' language of Cocoa, there are Java bindings. Note - this API is NOT Swing - it is a MacOSX extension API. Consequently, a MacOSX application built in Java should be almost indistinguishable from a native compiled app in terms of look and feel. And according to your comments, performance is also indistinguishable.
I have played with Java bindings for Gnome; they provide blindingly fast gui performance, using the same java runtime as is used by Swing. However, there are several java binding projects for Gnome (all partially complete), and none of them really address the general problem of widgeting across platforms.
I have also played with Eclipse, the IBM Java . Their widget toolkit is cross platform in API but system native in widget; however, I have found the performance of the Eclipse widget set to be almost as bad as Swing. However, it is beta code - we may have to wait and see if anything improves with age.
Java/Gnome demonstrates that it can be done under X. Eclipse demonstrates that it can be done cross platform. MacOSX demonstrates that it can be done well enough as to be indistinguishable from system native widgets.
So can anyone tell me: WHY hasn't it been done? (And don't say its because they don't want to break backward compatibility - Look at 1.4's NIO framework and VolatileImage).
Russ Magee %-)
Re:skeptical for the desktop (Score:1, Interesting)
Java *can* be made to run as fast as C/C++ apps but it's rare and only for certain applications of Java. Different compiling and runtime techniques technique such as JIT compiling and using HotSpot can get "primitive functions" - those on arrays of int, floats, etcetera to near comparable C/C++ code. However, the Java built-in libraries have enough built-in bloat to make further promises of speed indistinguishability just plain misleading ("it works fine, just avoid this list of 50 poorly implemented classes"). No, Java the language isn't slow, but Java the set of Sun library implementations has many, many deficiencies.
Also, I wasn't saying that all of Java is one big bug but you can't argue that there are a tremendous amount of bugs in Java's standard APIs. Things like horizontal scrolling not working for JTables. [sun.com] I mean c'mon, really - that's just a standard bounds checking and listener notification algorithm and the bug has been around since 1998. I know JTree has major problems (e.g., node rendering of icons works differently for nodes being edited than those not) and the DefaultTreeNodes in the Java API are overwritten to no end other than inefficiency. Drag and drop doesn't work with multiple items, thus almost no one ever uses DnD in the apps I work on - hell, even I don't because at least I can rely on copy and paste. Well, within the same application, actually, outside of the same VM trouble starts.
It's even cooler though, because the "write once, run everywhere" of Java actually works if you write good code).
Well yes, it runs, but it is far from guaranteed that it runs _well_. I took some of my company's Java apps that ran well under Windows and tried them under OS X and they were dog slow. At one point I managed to get ProcessViewer to report CPU usage over 100%! Highlight some text in your browser - that's what it does. Two simple math coordinate checks, a couple calls to drawRect and drawChars, written about as efficiently as Java allows but with every set of mouse movements I saw the CPU usage shoot through the roof. [The reason I made a custom class for this was because JTextArea and JEditPane were horrendous due to my need for special formatting - I have literally 50 times better performance now than with JEditPane and about 10 times better performance than with JTextArea on my wintel machine.] I know JBuilder runs fine on my machine (I suspect some Mac-specific code or vm settings) but Java isn't at all guaranteed to run well across platforms. Of course, my machine is 3 years old - so is Java 1.2 SE but as I was saying, Sun relies on hardware to catch up. I'm sure it would run fine on a 1 GHz dual processor G4. [Actually I think graphics cards have a large part in Java's performance.]
they assume that anything that is fast, stable and looks and feels platform native wasn't written in Java
Believe me, when something crashes that means to me that it wasn't written in Java. I have never dealt with another language so stable. Even when internal exceptions are thrown I've seen apps soldier on through their own bad states and actually still work, though they do of course become flaky. LnF hasn't really been much of an issue either - Windows and Linux have always looked like crap (haven't tried XP yet) so I've never expected Java apps on either of them to look good and really wouldn't care if widgets on them weren't completely "native-looking". On Mac, it looks sweet except for text rendering. It really is the performance problems and the bugs in Sun's libraries that are the worst thing about Java. The bugs are actually probably more annoying because they are the let-downs "Oh, look it has this great gui widget" and then ten days later "Oh crap that widget has a horrible bug and I'm completely reliant on Sun to fix it or else I have to either write my own version of that widget or steal their source, fix it, recompile it and then only be able to use it internal to the company." It's not a great working method - if they allowed for people to make fixes to Sun code instead of all of us having to either live with the bugs or rewrite entirely new classes, Java would have a much better set of library implementations. Instead people like me have to decide whether we can spare the time to write whole new versions of objects with the same functionality but, well, functional, or tell our boss and have our PR tell our customers "Yes, we know that doesn't work right. It's a problem with Java and there's nothing we can do to fix it." Believe me, as a professional programmer I can tell you that happens over and over again and it is a situation that benefits no one (well, except if you have direct competition that isn't reliant on sun's java libraries, then they benefit).
Wording was bad (Score:5, Interesting)
Now if you think
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
Re:My pet peeve. (Score:3, Interesting)
You probably don't want to strengthen patents any more than they already are, because we're already seeing all kinds of problems with software patents being used to lock open source solutions out of various areas. Many industries also have the problem that start-ups are impossible because the established players already own the necessary patents, and have no interest in licensing them to a new competitor.
Personally, I suspect that the answer is probably a compulsory license [cptech.org] regime for patents. In this case, a sensible solution might be to set default payments which are somewhat high, but that scale with number of units sold and price charged. Thus, large corporations still have an incentive to negotiate with patent holders for lower license fees, but start-ups needn't pay anything until they start shipping units, and would be free to use the patents at that rate whether or not their competitors want to let them into the market. Finally, free software would be protected, since in this scheme the developers would be implicitly accepting the default terms, which wouldn't require payment for copies not being charged for (but RH et al would have to fork out for distros that they sell).
Unsurprisingly, a number of powerful lobbies have ensured that this cannot happen without major changes to our IP system; for one thing, it would require breaking the WIPO treaty, which the megacorps paid really good money for.
Re:Still no GUI fixes? (Score:2, Interesting)
Re:Headless at last - bye bye XVfb (Score:3, Interesting)
I'm kind of interested in java.awt.image.VolitileImage. It makes an image using the video card's memory, with the trade off that the image may be destroyed at any moment. I've done some tests and on my machine it didn't improve performance at all, but on a system with a good video card, it may be an awesome class.
Re:It's a big step up, but there is still distance (Score:4, Interesting)
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).
Re:It's a big step up, but there is still distance (Score:1, Interesting)
Apache was designed for reliability over speed. Try benchmarking against Zeus, NES, or phttpd if you want a reasonable comparsion (single-process server vs single process server).
Re:My take on JDK 1.4 (Score:2, Interesting)
I'm not sure how much C# coding you've done. In recent months I've written quite a bit of C# and .NET code. Let me enlighten you with regards to the implication that C# is either not proprietary or cross platform.
It may be true that C# - the language - is cross platform and may acheive recognition as a standard of some sort. However, the .NET framework (which almost every C# program written uses) is not cross platform nor will it be a standard.
Why? Because of small details in the API. Let me give an example. Let's say you want to find out what operating system your program is running on. In Java, you do this:
System.out.println( System.getProperty( "os.name" ) +" " + System.getProperty( "os.version" ) );
Looks pretty straight forward. In C#:
using System;Console.Writeline( System.Environment.OSVersion.Platform );
Now this all looks very nice. The problem is that the Java version gives you a string, and the C# version gives you a... enum. That's right folks, to find out what operating system you are running, the .NET platform gives you an enumerated integral constant. This means that you have three choices for which operating systems you can discover you are running on, and which operating system the operating system can tell you it is.
Those three choices are:(If you want to verify this yourself, check out the System.PlatformID enumeration.)
Now, how do you make this cross platform?
Re:Yah, will this be stable on Linux? (Score:2, Interesting)
Re:It's a big step up, but there is still distance (Score:2, Interesting)
Don't get me wrong, I'm using the NIO libraries anyway because my company's system needs them, but I was running into a new bug a week for a while. I was hoping they'd have fixed at least the major ones by the time it became official. The workarounds for some of them are just awful.
My major sore points: