Discussions

News: Sun Prepares to Unleash Java 'Tiger'

  1. Sun Prepares to Unleash Java 'Tiger' (24 messages)

    The new version, J2SE (Java 2 Platform, Standard Edition) 1.5, will add technology from ongoing JSRs (Java Specification Requests) that will simplify development and smooth the language in four areas: ease of development; monitoring and manageability; scalability and performance; and XML and client-side Web services support, officials said.

    Sun Prepares to Unleash Java 'Tiger'.

    When I see statements like:

    But some developers say, as far as the ease-of-use issue goes, Sun's work may be too little, too late. "It's simply too late," said Adam Madrak, a consultant and software developer in Drexel Hill, Pa. "I'm a LAMP [Linux, Apache, MySQL and PHP] guy now."

    I have to wonder how true they are. I supervise a group of J2EE developers some of which learned Java while at the company. None have had a problem with the "complexity" of Java. What's up here?

    Threaded Messages (24)

  2. FYI, Joshua Bloch (who was quoted in this article) will have a tech talk published on TSS this week.

    Floyd
  3. I think, Lots of options to do one thing in Java makes people feel that Java is hard.
    I am working on a VB.NET project and a J2EE project at same time and I do not find Java any difficult as compared to VB.NET. At times I find Visual Studio lot inferior to Eclipse, support for refactoring, local history of file, managing imports etc.

    I think sticking to one set of tools for development in Java helps a lot.
  4. Interesting that you mention Eclipse. We standardized on this platform about a year ago and I'm not sorry I made that choice. I think you can get overwelmed by J2EE if you try to use all of it instead of focusing what you really need. We pretty much stay with POJOs wrapped in session beans. Our data cache is also housed in a session bean.
  5. Steven,

    Could you elaborate bit how you do it?

    thanks
     
    Frank
  6. Basically a HashMap is used to store results sets by name from a statement list. This is great for interactive apps that require multiple SQL statements to be executed in sequence across systems/databases to populate a form. You can scroll through cached results, remove them from the map, etc. The session bean is a wrapper for the db cache classes which provides transactions, passivation (keep the memory foot print smaller), etc.

    I'm working on making this work across a cluster, so I may move to JCache or something similar/
  7. Refactoring IDEs[ Go to top ]

    I think, Lots of options to do one thing in Java makes people feel that Java is hard.

    > I am working on a VB.NET project and a J2EE project at same time and I do not find Java any difficult as compared to VB.NET. At times I find Visual Studio lot inferior to Eclipse, support for refactoring, local history of file, managing imports etc.
    >
    > I think sticking to one set of tools for development in Java helps a lot.

    IMHO, I find IntelliJ IDEA far superior to VS.NET for many of the same reasons that Eclipse is eclipsing VS.NET. The Java community, as a whole, seems to have a bit more maturity with regards to development philosophies (XP, refactoring, layered architectures, patterns, best practices), and this maturity is starting to embody itself in the types of tools that we're using. 3 years ago no one was really keyed into XP and refactoring (except for the Smalltalkers ;-) Now everyone in the Java community is talking about these features within their IDEs, or dumping their antiquated IDEs for Eclipse or IntelliJ (coming from an ex-NetBeans user).

    If you go to any of the .NET sites (and I have), their collective focus seems to be at discovering how to do basic things using the wizards and what not in VS.NET. Not many people are talking about architectures or overall best practice designs. And VS.NET needs to come a long way before it moves up to the league Eclipse and IntelliJ are currently playing in. Maybe SharpDevelop will becoming the Eclipse/IntelliJ of the .NET/Mono world.

    Regards,


    -- chris bartling --
  8. Refactoring IDEs[ Go to top ]

    Or Eclipse will become the Eclipse of the .NET world. There are some plug ins that support .NET already available (for a while now) for Eclipse. Can't beat the price either.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  9. Refactoring IDEs[ Go to top ]

    While I think, refactoring is very nice and useful, I think it is quite dangerous to use it as a general development principle. Generally, it is still better to make up your mind before you build something rather than afterwards or in the process of doing something. On the other hand tools like intellij introduced some great things in the java ide world (ok introduced might be a bit to strong, let's say: made widely known), like find variable usage, goto implementation etc. As far as I know, these are things that were available in VS for years.

    As for architecture discussions: In a way a tool like VS defines a lot of standardized architecure. Conceptually this is a lot different than a tool like idea, basically a hacker's ide that is very code geared - I like it. But it is not for everyone nor can we be really sure that it is the superior concept. For example VBX Controls are a tremendous successfully concept. There still is nothing like it in the Java World. JavaBeans did not live up to the initial promise to provide something similar.
  10. ActiveX versus JavaBeans[ Go to top ]

    For example VBX Controls are a tremendous successfully concept. There still is nothing like it in the Java World. JavaBeans did not live up to the initial promise to provide something similar.


    JavaBeans do live up to the promise, it's the developers that don' t really use the technology. Java is mainly used at the server-side, so why spend your time building JavaBeans? I have seend very good examples of JavaBeans that where extremely usefull and operate just like ActiveX but I know very little Java programmers that use Swing based clients. Most people use JSP / Servlet...
  11. Comparing Java IDEs[ Go to top ]

    I was wondering how Oracle's JDeveloper compares to Eclipse or IDEA?? It seems to have a nice list of features (UML modelling tools, embedded server for debugging, ...), but I still find it to be somewhat cumbersome to use. Basically, I find that the fine-grained touch-stroke savings of working with 'vi' still significantly outweigh the fancier innovations of things like code completion. I would like to find an IDE that implements a 'vi' like front-end. I know that Together supposably does, but it is out of my price range.
  12. Comparing Java IDEs[ Go to top ]

    JDeveloper is just perfect for the position
    between oracle database and 9iAS. It has integrated
    database access with pl/sql editor,
    debug/deploy on internal or external
    9iAS (oc4j), and all other stuff (junit,
    ant, xml, ejb, some uml.........).

    Outside Oracle stack, I, personnaly, prefer Eclipse.

    AlexV.
  13. But some developers say, as far as the ease-of-use issue goes, Sun's work may be too little, too late. "It's simply too late," said Adam Madrak, a consultant and software developer in Drexel Hill, Pa. "I'm a LAMP [Linux, Apache, MySQL and PHP] guy now."

    >

    J2EE doesn't play in the same league as Apache, MySQL and PHP; it's goals are so much broader. I'm not sure if anyone that would make such a statement can be taken too seriously.
  14. I agree, you could replace that sentence with Linux, Apache, MySQL and JSP (LAMJ).
  15. What exactly is a "static import"?

    Enumertated types will be a blessing. Will they support inheritance?

    They didn't get generics right in my opinion. Not allowing generics to work with basic types is going to kill them for any useful purpose.
  16. What exactly is a "static import"?

    >
      use "abs()" instead of "Math.abs()", ....

    > Enumertated types will be a blessing. Will they support inheritance?
    >
    > They didn't get generics right in my opinion. Not allowing generics to work with basic types is going to kill them for any useful purpose.

    Primative types are supported through auto-boxing.
  17. Sun Prepares to Unleash Java 'Tiger'[ Go to top ]

    hope it will be "NUMBER.abs()" instead of "abs(NUMBER)" ...
  18. enumerated types[ Go to top ]

    Enumertated types will be a blessing. Will they support inheritance?


    I would imagine not. The weird thing about enumerated types is that type-safety would would exactly opposite as you would normally expect.

    Consider the example of general fruits and citris fruits. You'd think that citris fruits are a subset of general fruits so they should be a subclass of fruits, however, if you wanted to implement them in terms of enumerated inheritance, you'd get:
    . . enum Citris {Orange, Lime, Lemon};
    . . enum Fruit extends Citris { Apple, Pear } ;
    But even this wouldn't be good since if you pass a fruit to the following function:
    void shouldNeverFail(Citris c) {
    . assert(c==Orange || c==Lime || c==Lemon);
    }
    it would assert even though the designer of this class rightfully assumed that it shouldn't.

    What you're looking for is not inheritence, it's set unions. So Fruit would be defined as:
    . . enum Fruit = { Apple, Pear } || Citris ; // Where || is defined to be set union
    With set unions, you can pass a Fruit into a method expecting a Citris but not vice versa.
  19. Eh?[ Go to top ]

    What you're looking for is not inheritence, it's set unions. So Fruit would be defined as:

    > . . enum Fruit = { Apple, Pear } || Citris ; // Where || is defined to be set union
    > With set unions, you can pass a Fruit into a method expecting a Citris but not vice versa.

    Er, shouldn't that be the other way around? Since Citrus is a subset of Fruit, you should be able to pass a Citrus to any function expecting a Fruit, but not the other way around.

    Regards,
    Ganesh
  20. Eh?[ Go to top ]

    . . enum Fruit = { Apple, Pear } || Citris ; // Where || is defined to be set union

    > > With set unions, you can pass a Fruit into a method expecting a Citris but not vice versa.
    >
    > Er, shouldn't that be the other way around? Since Citrus is a subset of Fruit,
    > you should be able to pass a Citrus to any function expecting a Fruit, but not
    > the other way around.

    Yes, of coarse.;-O
  21. Enumerated types will be a blessing. Will they support inheritance?

    More importantly, how will they interact with classloaders - the initial documents I've seen just put them in as a language feature that wraps to Sun's enum pattern under the skin. However, there are known issues with that pattern that mean that if the same enum is loaded by different classloaders, it will be seen as being different...

    Really think they need to address this.

    They didn't get generics right in my opinion. Not allowing generics to work with basic types is going to kill them for any useful purpose.

    You just want C++ really, not Java, don't you? ;-)

    FWIW, I think they've struck a good compromise with the planned generics, allowing much inproved type safety/reuse, without allowing some of the more extreme uses that things like Todd Veldhuisen's Template Meta-programming in C++...

    http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html

    ...if you've ever done C++ Templates you might enjoy it. Alternatively, you might be appalled by the concept of a program that runs it's logic in the compiler, and the object code/executable gets discarded.

    /david
  22. ...if you've ever done C++ Templates you might enjoy it. Alternatively, you

    > might be appalled by the concept of a program that runs it's logic in the
    > compiler, and the object code/executable gets discarded.

    Templates in C++ can do some really amazing things, but there's much less of a need for them in Java since Ant and XDoclet already provide much of this functionality.

    One way templates are logistically superior in Java (IMO) is that you can assign the template List<Type> to List so you can pass templated collections to legacy classes that expect "List" arguments.That upgrading your code to templates much easier and reduce the need for parallel implementations of templated and non-templated methods. And since all your old collection code already works with templates, using templates in your codes is no big deal.

    If C++ had templates and something like the STL from the beginning, like they were in Eiffel and Sather, templates would be pervasive in all C++ programs. Unfortunately it didn't work out that way. When templates were introduced into C++ several years later, they didn't catch on quickly because legacy libraries had to be rewritten to use them and several had to have parallel implementations. As a result of the pain an portability problems, many projects even today have "don't use templates" as part of their coding guidelines (e.g. http://www.mozilla.org/hacking/portable-cpp.html#dont_use_templates ).

    The Tiger template implementation has a run-time cost (an implicit downcast) but I think it's worth it.
  23. Typesafe enum[ Go to top ]

    Enumerated types will be a blessing. Will they support inheritance?

    >
    > More importantly, how will they interact with classloaders - the
    > initial documents I've seen just put them in as a language feature that
    > wraps to Sun's enum pattern under the skin. However, there are known
    > issues with that pattern that mean that if the same enum is loaded by
    > different classloaders, it will be seen as being different...

    I came across a similar problem when passing serialised typesafe enums via JMS, though I came up with a workaround. Don't know if anyone's interested, but here's what I did:

    I have an abstract base TypeSafeEnum class which implements Serializable and is overridden to create specific enum types. Each instance of TypeSafeEnum has a unique ID. Descendent classes have 'public static final' fields of their own type, each of which holds an enumeration instance. TypeSafeEnum has an abstract getInstances() method which each derived class must implement; this must return a Map which contains all the instances (i.e. enumerations) of the derived class keyed on their ID (the derived class should generally set up this Map in a static initializer).

    Then, my base TypeSafeEnum has a static method as follows:

        protected static final TypeSafeEnum forId(Map registeredInstances, String id) { ... }

    ...which allows you to lookup the TypeSafeEnum object from the Map for a given ID. TypeSafeEnum then implements the readResolve() method as described in the documentation for java.io.Serializable (but not defined in the interface!) as follows:

      private Object readResolve() throws ObjectStreamException { return forId(getInstances(), this.id); }

    The effect of this is that when an instance of a TypeSafeEnum descendent is created from a serialised stream, the actual instance object returned is the local classloader's existing matching copy as defined by the class' public static final field.

    The upshot of all this is that you can still reliably compare enum references using '==' and '!=', though it's quite a lot of effort to go to though, for a small gain. Unfortunately, this won't (in general) get round the 'different classloaders' problem.

    Al.
  24. 'Tiger' might be a good name for a release that actually fixes fundamental Java language flaws.

    Seems to me that this release should be called 'kitten'.
  25. RowSet implementations?[ Go to top ]

    Does anyone know whether stable implementations of the RowSet interface, such as the CachedRowSet, JDBCRowSet and WebRowSet classes from the Early Access releases, will be included in J2SE v1.5? I've been using EA4 on and off for a while, but results (no pun intended) are inconsistent.

    J