Forgot your password?
typodupeerror
Java Programming

Java2 SDK v. 1.4 Released 362

Posted by michael
from the cuppa-joe dept.
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.
This discussion has been archived. No new comments can be posted.

Java2 SDK v. 1.4 Released

Comments Filter:
  • by LarsWestergren (9033) on Thursday February 14, 2002 @04:29AM (#3005756) Homepage Journal
    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]
  • Asserts (Score:3, Informative)

    by Malc (1751) on Thursday February 14, 2002 @04:44AM (#3005792)
    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.
  • Re:Java2 ? (Score:4, Informative)

    by LarsWestergren (9033) on Thursday February 14, 2002 @04:52AM (#3005811) Homepage Journal
    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.
  • by autopr0n (534291) on Thursday February 14, 2002 @05:00AM (#3005828) Homepage Journal
    I guess it would be nice to have SSL built into java, but you could write it yourself, it's not like it's a fundementl language flaw. The specs are out there, and the java Crypto API would probably help you out quite a bit.
  • AUTOEXEC.BAT (Score:3, Informative)

    by autopr0n (534291) on Thursday February 14, 2002 @05:05AM (#3005835) Homepage Journal
    Throw the classpath in your AUTOEXEC.BAT file on the C: drive on your win98 machine. Should work.
  • by Aceticon (140883) on Thursday February 14, 2002 @05:20AM (#3005865)
    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???

  • by mccalli (323026) on Thursday February 14, 2002 @05:28AM (#3005874) Homepage
    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

  • Patent titles (Score:5, Informative)

    by jeti (105266) on Thursday February 14, 2002 @05:37AM (#3005887) Homepage
    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
  • by Wraithlyn (133796) on Thursday February 14, 2002 @05:39AM (#3005889)
    "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
  • by srichman (231122) on Thursday February 14, 2002 @05:42AM (#3005893)
    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].

    ???

  • by _am99_ (445916) on Thursday February 14, 2002 @06:00AM (#3005924)
    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.
  • by mlinksva (1755) on Thursday February 14, 2002 @06:01AM (#3005927) Homepage Journal
    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.
  • Re:Genericity? (Score:4, Informative)

    by srichman (231122) on Thursday February 14, 2002 @06:12AM (#3005946)
    1.5 [javaworld.com]
  • by asb (1909) on Thursday February 14, 2002 @06:13AM (#3005947) Homepage
    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.
  • Ironic/NBIO (Score:5, Informative)

    by srichman (231122) on Thursday February 14, 2002 @06:25AM (#3005966)
    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.)
  • by Anonymous Coward on Thursday February 14, 2002 @06:37AM (#3005982)
    Swing is much faster on linux, and it is about
    8-10 times faster on a remote X session.
  • Re:J2EE openness (Score:1, Informative)

    by Anonymous Coward on Thursday February 14, 2002 @06:39AM (#3005986)
    Opensource J2EE implementation available at
    www.jboss.org
  • by Speare (84249) on Thursday February 14, 2002 @07:14AM (#3006063) Homepage Journal

    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.

  • by TheAJofOZ (215260) <adrian.symphonious@net> on Thursday February 14, 2002 @07:17AM (#3006067) Homepage Journal
    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:Good articles (Score:2, Informative)

    by joyrider (128966) on Thursday February 14, 2002 @07:30AM (#3006101)
    Wrox Press [wrox.com] have an Early Adopter J2SE 1.4 [amazon.com] book out now, and it's got some good reviews at Amazon...

  • by divec (48748) on Thursday February 14, 2002 @07:56AM (#3006160) Homepage
    • 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 peeve. (Score:2, Informative)

    by AVee (557523) <slashdot@avee.oMENCKENrg minus author> on Thursday February 14, 2002 @08:10AM (#3006197) Homepage
    Read the ZDNET article [com.com]:
    "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)

    by Anonymous Coward on Thursday February 14, 2002 @08:15AM (#3006211)
    I'm so sick of reading this anti-Java crap by people who either (a) haven't used java or (b) have only written small projects in C/C++. I just can't believe the assertions being made by some people.

    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 ... almost zero.

    * 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.
  • by Anonymous Coward on Thursday February 14, 2002 @08:25AM (#3006235)
    Here we go again:

    ...you can't write your own class BetterString...
    Thank God, broken or not.
    A function cannot take variable arguments
    Easy answer: quit trying to write C code in an OO language and this won't be a problem.
    You can't create a list anonymously
    Try "average(new int[] {x,y,z})".
    Things that should be warnings are in fact errors
    Translation: things that screw you in other languages can't screw you in Java. Funny, I don't ever get these error messages, perhaps because I never learned to be lazy with my declarations.
    The syntax is intentionally inflexible
    Translation: the syntax is mercifully consistent from program to program.

    Just go write your C programs and quit complaining why Java isn't more like C.

  • by Taurine (15678) on Thursday February 14, 2002 @09:10AM (#3006384)
    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.
  • by JohnA (131062) <<moc.liamg> <ta> <nosrednanhoj>> on Thursday February 14, 2002 @10:11AM (#3006651) Homepage

    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.

  • by _underSCORE (128392) on Thursday February 14, 2002 @11:18AM (#3007378) Homepage Journal
    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++.
  • by toriver (11308) on Thursday February 14, 2002 @12:00PM (#3007746)

    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.

  • by melquiades (314628) on Thursday February 14, 2002 @01:02PM (#3008170) Homepage
    i don't like the fact that they added an Assert keyword but I don't get to make the decisions.

    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:

    2. Why does this facility justify a language change, as opposed to a library solution?


    We recognize that a language change is a serious effort, not to be undertaken lightly. The library approach was considered. It was, however, deemed essential that the runtime cost of assertions be negligible if they are disabled. In order to achieve this with a library, the programmer is forced to hard-code each assertion as an if statement. Many programmers would not do this. Either they would omit the if statement and performance would suffer, or they would ignore the facility entirely.

    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.
  • by The Mayor (6048) on Thursday February 14, 2002 @01:05PM (#3008191)
    They are upset because they offered log4j to Sun as part of the JCP to include in JDK1.4....and Sun rejected it, pushing their own implementation instead. The idea of the JCP being run by the community is a crock of shite. Sun has pushed a number of inferior standards through it, most of which are used more frequently than the superior product because many programmers are simply too lazy to use the superior product.

    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.
  • by Anonymous Coward on Thursday February 14, 2002 @01:22PM (#3008310)
    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)

    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.

  • by Glock27 (446276) on Thursday February 14, 2002 @02:16PM (#3008648)
    OK.. I am a Java fan... (recently this has been changing though.)

    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!

  • by Dr_LHA (30754) on Thursday February 14, 2002 @02:41PM (#3008818) Homepage
    kernel: kernel BUG at pktcdvd.c:1046!

    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!



Never invest your money in anything that eats or needs repainting. -- Billy Rose

Working...