7 Replies Latest reply: Feb 16, 2004 6:53 PM by 843853 RSS

    JDK1.5 (Tiger) and JCP

    843853
      Hi,
      a beta of JDK1.5/Tiger is supposed to be out by the end of the year. We've heard million times about the new language features (generics, autobox, ...) but nobody ever mentions which of the additional JCP will make it. The list of JCP supposed to be in 1.5 can be found at

      http://www.jcp.org/en/jsr/detail?id=176

      here it is:

      JSR-003 JavaTM Management Extensions (JMXTM) Specification
      JSR-013 Decimal Arithmetic Enhancement
      JSR-014 Add Generic Types to the JavaTM Programming Language
      JSR-028 JavaTM SASL Specfication
      JSR-114 JDBC Rowset Implementations
      JSR-133 JavaTM Memory Model and Thread Specification Revision
      JSR-163 JavaTM Platform Profiling Architecture
      JSR-166 Concurrency Utilities
      JSR-174 Monitoring and Management Specification for the JavaTM Virtual Machine
      JSR-175 A Metadata Facility for the JavaTM Programming Language
      JSR-199 JavaTM Compiler API
      JSR-200 Network Transfer Format for JavaTM Archives
      JSR-201 Extending the JavaTM Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import
      JSR-204 Unicode Supplementary Character Support
      JSR-206 JavaTM API for XML Processing (JAXP) 1.3

      In particular I'm interested in JSR-174 and JSR-163.
        • 1. Re: JDK1.5 (Tiger) and JCP
          843853
          Java should introduct "this" in static method. It refers to the receiver class object, just like in instance method "this" refers to the receiver's instance object.

          Then we have a uniform inheritance framework.
          • 2. Re: JDK1.5 (Tiger) and JCP
            843853
            Is there any chance of newer version of the 1.5 prototype compiler
            before the beta release, preferably one with unboxing?

            -Eric
            • 3. Re: JDK1.5 (Tiger) and JCP
              843853
              JDK 1.5 alpha (beta) is out and online on
              http://java.sun.com/developer/earlyAccess/j2sdk150_alpha
              However, I was unable to compile any of the mentioned new features (generics, autoboxing, enchanced for, enums)... Can somebody provide an example of a small program (showing the new features) that could be compiled via

              java version "1.5.0-beta"
              Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b31)
              Java HotSpot(TM) Client VM (build 1.5.0-beta-b31, mixed mode)

              (This is what "java -version" returns for me. I'm not sure why it states "beta", but the URL that I've downloaded it ends "alpha".)
              • 4. Re: JDK1.5 (Tiger) and JCP
                843853
                Yes! I did it!
                Just compile with -source 1.5, i.e.
                javac -source 1.5 Test.java
                Only then the new compiler uses the new features, otherwise it runs like 1.3
                • 5. Re: JDK1.5 (Tiger) and JCP
                  843853
                  Does anyone know what is the package name for the profiling api ?
                  • 6. Re: JDK1.5 (Tiger) and JCP
                    843853
                    For that matter, is there API documentation anywhere for the new features in JDK1.5?
                    • 7. Re: JDK1.5 (Tiger) and JCP
                      843853
                      You can find various documents such as:

                      http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html

                      and

                      http://java.sun.com/developer/technicalArticles/releases/j2se15/

                      The latter is the first place I read about formatted output (C style string formatting with the %d's and %s's)
                      and Varargs (scripting language (lisp/python) style 'we have no idea how many paramters this method takes')

                      A lot of these 'small' changes seem to be things that are probably one or two peoples favourite 'features' from some other language(s). Let me add mine to the list then:

                      I really like how in C you could use an integer in a logical statement eg:

                      int n = someFunction();
                      if (n) {
                      return someOtherFunction() / n;
                      } else {
                      ....
                      // throw an exception?
                      }

                      Now, okay, the statement "if (n)" is really just syntactic sugar for "if (n != 0)", but it looks nice and would be fairly easy to do.

                      However: let me just say that I am a very conservative Java programmer. I cut my Java teeth on 1.01. I'm a bit of a luddite really when it comes to adding features to a language... and I hate what they've done with 1.5.

                      In fact, I loathe it with a passion. I despise it. I spit on the ground that it walks on.

                      I didn't like regex (in 1.4 I think) either, and for much the same reasons.

                      Under no circumstances should we be taking on board features from languages that are harder to read than Java.

                      "Eh?" I hear you say.

                      Let me put it this way: readability is next to maintainability.

                      "What's the big deal?" you might ask. "After all, you're a really good programmer, I'm a really good programmer, these new features will make me (fractionally) faster and more productive, it's all good, right?"

                      And thats probably true for some people. I mean, particularly the engineers/architecture astronauts at Sun, they're surrounded by brilliant people, who write brilliant code all day long.

                      In many ways, I envy them. I do not work with brilliant people, or brilliant code.

                      The sort of places I've worked they have code that has maintenance comments that are over ten years old.
                      Code that noone working in the IT sections at that time is left that even knew the original maintainers (let alone the ancient and semi-mythical orginal coders). (No Java code is this ancient of course... yet...)

                      I work in places where there are a lot of people new to Java programming. Some of them have no prior exposure to programming. Some of them have over 20 years of programming, but have never been exposed to OO before. None of them are 'stupid', but some of them are 'pretty average'. Some of them jump right in and start swimming straight away. Others of them I have to go in and regularly pull them out because they're out of their depth and drowning.

                      Even the ones that take to it like a fish to water come up with some pretty strange stuff every now and then.

                      Guess who ends up having to debug their code?

                      I work in places where some previous projects were outsourced to India (true story: one place I worked in NZ they were considering outsourcing the project to India - until they discovered that we were cheaper than the Indians(!!!) - I have no idea what they would have ended up with if they'd gone with the Indian option, since their requirements had been very poorly specced out... but that's another story).

                      There are two really good things about the Indian programmers code that I'm working on at the moment
                      (1) It works (mostly)
                      (2) It is very consistent in its style

                      The downside, is that the style they used is not the standard Java style. They do not use standard Java naming conventions (everything starts with a capital letter), they use really really long variable names, don't use whitespace (or use it improperly - more about that later) and they line break at the 70-80 character mark, which means that code like this:

                      a = b + c;
                      B.x(y).z;

                      turns into this (variable names shortened to protect the sanity):

                      A =
                      Bb +
                      C;
                      B.
                      X(
                      Y
                      ).Z;

                      You gotta love it. Oh wait, no, no you don't. (For 200 points, select all the static method calls in this 15000 line file (no, seriously!)).

                      I'd never seen the following use of whitespace before, but by gosh it makes it hard to follow the code

                      if(X)
                      {
                      .... do something
                      }

                      // some comment
                      else if(Y.Z)
                      {
                      .... do something else
                      }

                      // some other comment. Aren't comments nice? We're such good programmers! Yay us!
                      else
                      {
                      ... etc ...

                      My point: (and I do have one)
                      Is that even with the existing Java features, if you really want to, you can go out and write some really appallingly hard to read code. Not quite the perl (read this in six months? Ha! I can't read this 6 minutes later! Muahahahaha!!!!):

                      erwg#$^4[5]6rthr+3246{3245ewr%$-@^#%&twert}

                      if you know what I mean, but still darn hard to read and debug.

                      These new features are just going to get abused by new/inexperienced programmers. If I'm looking at code that some young programmer has written, I don't want to have a lot of stuff happening offscreen with smoke and mirrors, I want it to be very very explicit.

                      In general for debugging smoke and mirrors are bad. I like RMI because its really really simple, yes, there's smoke and mirrors happening with the stubs and skeletons, but they're okay because you can understand what's going on very easily (which didn't stop some $%^#% from writing up the pages on RMI and intermingling the version 1 and version 2 explanations, which made it about an order of magnitude more complicated than it should have been - whoever it was did an enormous disservice to RMI and other networking technologies like Jini).

                      I sympathise with the geniuses for whom the compiler is their only minion. Yes, they would want to have it do as much of the programming load as possible... but if I have to come down from my laboratory in the castle, and help the apprentice evil geniuses figure out whats wrong with their project... I want to make darn sure that if the monster is moving its because its alive, not because their Igor is pulling a few nearly invisible strings...

                      Executive summary: bad dog, no biscuit.