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 btempleton (149110) on Thursday February 14, 2002 @04:19AM (#3005731) Homepage
    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.
  • 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
    • Ruby vs. Java (Score:2, Insightful)

      by srichman (231122)
      I'm a big fan of Ruby, and a diehard Java devotee.

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

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

  • 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]
  • by Yakman (22964) on Thursday February 14, 2002 @04:32AM (#3005764) Homepage Journal
    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 (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:Asserts (Score:2, Funny)

      by utdpenguin (413984)
      Assertions can be dangerous. Many people make confident assertions about subjects concerning which they have little knowldge. For example, me talking about coding. :)
    • Re:Asserts (Score:3, Interesting)

      by Anonymous Coward
      Yes. Asserts are easy to use and have a huge payoff. They are especially good at catching nasty subtle bugs.

      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 ...
    • Unit testing (Score:3, Insightful)

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

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

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

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


      This uses almost no CPU-time if debugging is disabled. Log4J is a very good logging package, it surely beats System.out.println, check it out!
  • J2EE openness (Score:2, Interesting)

    by prockcore (543967)
    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?

    • Wording was bad (Score:5, Interesting)

      by SuperKendall (25149) on Thursday February 14, 2002 @11:28AM (#3007466)
      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? (Score:3, Insightful)

    by hephro (166117) on Thursday February 14, 2002 @04:49AM (#3005804) Homepage
    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? (Score:2, Interesting)

      by Westley (99238)
      The proposed generics proposal are all compiled into the bytecode anyway, I believe. There's a prototype compiler (which generates bytecode which can be used with the normal JRE) available here [sun.com].

      Jon

    • Re:Genericity? (Score:4, Informative)

      by srichman (231122) on Thursday February 14, 2002 @06:12AM (#3005946)
      1.5 [javaworld.com]
      • Re:Genericity? (Score:2, Interesting)

        by gatesh8r (182908)
        From the article:

        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.
        • Re:Genericity? (Score:3, Flamebait)

          by Twylite (234238)

          Java will support parametised types, not templates. C++'s solution is a hack, and most people know that. True language (and VM) support for parametised types will not involve any binary bloat. In a way you can think of it as having a "object type" attribute and doing an "instanceof" to check that the type is right.

        • You can use templates to make C++ put on a pink tutu and dance a little dance for you. Alexandrescu [amazon.com] uses them, for instance, to make C++ forcibly multiply inherit a chain of classes into a single child class. He also has a single inheritance template setup and a lot of other sick and twisted stuff that every C++ programmer should at least know about.
      • Re:Genericity? (Score:3, Interesting)

        by khuber (5664)
        1.5 [javaworld.com]

        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

      • still no generic data structures

      And I was recently delivered C++ code that used a class with a private constructor and const static instances, instead of good old fashioned enums (goodbye switch, hello if/else/if/else/if/else...). I initially assumed that it was a paranoid developer who'd read Effective C++ and didn't want to be passing uninitialised enums around. Turns out that it was written by a Java programmer who didn't know what an enum was.

      Java isn't just missing enums, it's beginning to remove them from the developer's toolkit, and that can't be a good thing.

  • by Florian Weimer (88405) <fw@deneb.enyo.de> on Thursday February 14, 2002 @04:49AM (#3005806) Homepage
    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.
  • by Larkfellow (265776) on Thursday February 14, 2002 @04:51AM (#3005809) Homepage
    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.
    • AUTOEXEC.BAT (Score:3, Informative)

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

      It must be hell on productivity working on Autopr0n, what with the spank sessions every thirty minutes or so.

  • by Marsh Jedi (244205) on Thursday February 14, 2002 @04:58AM (#3005823)
    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 (Score:4, Interesting)

    by burtonator (70115) on Thursday February 14, 2002 @05:08AM (#3005838)
    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. :)
    • Thanks for a well written article.

      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.
      [...]
      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.


      Now that Microsoft is kept busy plagiarising...oops, I mean creating a competing C#, perhaps Sun wont have to fear embrace and extend tactics against Java itself, and dares to open up a bit more to open source and open standards. Maybe they will even be forced to do it to survive.
    • 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

      • import java.net.*

        Yes, '*' is the lazy programmer's haven.

        Java is great, but wildcard imports just invite namespace clashes and poor documenation of dependencies in the software.

        Just using one import per class provides instant automatic source-code-level documentation of all the dependencies in a software project.
    • As far as C# vs .Java. I am really impressed with the CLR/CLI stuff. Right now, as it stands, Java is a proprietary language. Unless we see SUN Open Source Java (or push it through a standards committee), we *may* see a JDK 1.5... but no one will use it.


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

      • "no one will use [JDK 1.5]" is obviously an overstatement, but the sentiment agrees with my intuition: Sun needs to make concessions to the open source community (which are in its own interest!) over the next year, or a free .net implementation will start driving java out of the niches it inhabits and could inhabit in the free software world. Long term that consigns Java to being this generation's COBOL.
    • i don't like the fact that they added an Assert keyword...
      Why? It's not like it will realistically break anything, and it's far better than the usual Assert class and associated techniques.
      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.
      So use Log4J, nothing stopping you.
      The regexp package is not all it is cracked up to be either. I would recommend Jakarta ORO or Jakarta Regexp.
      Yeah, except that the better of the two (ORO) has inexcusable bugs, even after all the years it's been around.
    • 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 Richard_Davies (250599) on Thursday February 14, 2002 @08:12AM (#3006201)
      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.
    • 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.

      Then why on earth would they be upset? I never understood this line of thinking... if their product is better, people will use it. I for one am happy that there is finally a standardized approach to logging. If it seems it doesn't do enough to fit my requirements then I'll use some 3rd party logging package.

      So they didn't clone the log4j API, big boo hoo.

      • by The Mayor (6048)
        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.
    • 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 Glock27 (446276)
      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!

  • Good articles (Score:2, Interesting)

    by mattscape (264484)
    Are there some good articles out there (besides the sun ones) on how to use the new features?
    thx
    matt
  • Kodak invented OLE? (Score:3, Interesting)

    by blair1q (305137) on Thursday February 14, 2002 @05:12AM (#3005849) Journal
    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
    • by briansmith (316996) on Thursday February 14, 2002 @05:22AM (#3005866) Homepage
      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. (Score:5, Insightful)

    by Malcontent (40834) on Thursday February 14, 2002 @05:19AM (#3005861)
    This is in regard to the kodak suit.

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

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

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

    Sit on your ass doing nothing, wait for somebody else to do all the work. Then sue them and retire in the bahamas. It's the american way I guess. Sure beats working.
    • Re:My pet peeve. (Score:2, Informative)

      by AVee (557523)
      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...
    • Now that is a crap argument.

      1) You have no idea whether Kodak actually use this - the first patent, for example, would seem to cover introspection and/or the java activation framework. It seems likely that a kodak image browser might well use these ideas - just not as publicly as sun.

      2) Supposed you were a lone inventor, and patented your idea for eg everlasting bubble gum. Now some big company, say, Slugworth Chocolates, comes along, starts producing your stuff without your permission, promotes it more than you can possibly afford, and thus you never make any money out of your invention.

      This is precisely why we have patents. There are many reasons to criticise the patent process, but complaining that a big company is doing more with an idea than its inventor, and thus should be exempt from the law, is not among them.
      • Actually, some people like strong steady progress and innovation. Patents slow down the progress and restrict innovation because people effectively own ideas. An analogy to farming would be that many people in my area are starving, and I am the only owner of fertile land. However, I refuse to do anything with the land, I own it, and I want to sit on it.

        Patents should be restricted so that they are used only to recuperate money spent on R&D of the idea/concept/technology. This way researchers could, in theory, fund their own research, once they got the ball rolling. Under these restricted patents, your patent last for a very small amount of time, maybe a few years, and it can be cut short if you make enough money off of the patent so as to recover your R&D costs.
    • Re:My pet peeve. (Score:3, Interesting)

      by Captn Pepe (139650)
      You shouldn't dump too much on patent owners who aren't fully utilizing their patents -- most small inventors (whether they patent their invention or not) see large corporations swoop in and seize their work before they could possibily have capitalized on it. If they're lucky, they have a patent and a good understanding of patent law, and can thus make something off of the corporation in question. Usually not, though.

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

  • 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

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


      Hmm... I guess that since I Create C++ Programs that run on a Linux and Windows OS, I am in violation of this copyright.

      On a side note, if Kodak wins this, they will probably go after MS next due to the OOP syntax and the CLR of .NET
    • by Corrado (64013)
      Wow, can they get any more vauge than that!?!?
  • 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 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.
    • Notice of Automatic Software Updates from Sun

      This is a feature of Java WebStart - application developers can specify a minimum JRE to use and WebStart will automatically download it when it is not already present. Note that while Web Start has just become standard with JRE1.4, it will run even on JRE 1.1 and I would imagine this clause is in the separate Java Web Start download as well.

    • "the Software may automatically ... install... ("Software Updates"), which may require you to accept updated terms and conditions for installation."

      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?

  • by divec (48748)
    • 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.
  • 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.
    • You've always been able to use java.awt.image.BufferedImage to create dynamic images. The application I'm working on does that. But you are right that now you don't have to use xvfb (which I never thought was that big of a pain, but I like the -D solution better).

      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.
  • by Greyfox (87712) on Thursday February 14, 2002 @09:35AM (#3006488) Homepage Journal
    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.
  • by Xawen (514418)
    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 value of marriage is not that adults produce children, but that children produce adults." -- Peter De Vries

Working...