Discussions

News: J2SE Mustang Snapshots: Another experiment in openness

  1. The J2SE process seems to be getting more open. Sun has taken the snapshot idea from Tiger, and has improved it with their Mustang release. They have posted the first snapshot already (on build #12). They are also going to ship source bundles so you can find bugs in the code :) A new license is being used: Java Research License. This is claimed to be an improvement from the old SCSL one.
    Inspired by the success of the Tiger snapshots, today we posted the first of the Mustang Snapshots. We've made some significant changes this time around:

        
    • We've started earlier. You can get build twelve today. Yes, that's twelve as in 12. There aren't a whole lot of changes in this build, mainly just bug fixes and a few small enhancements here and there, but you'll see more change going forward as new features are integrated.

        As usual, snapshot builds are not for the timid. They receive only limited testing -- just a few hours' worth to make sure that they're warm and breathing. If you want stability then you'd best wait for the Mustang beta release, but if you enjoy living on the bleeding edge then these builds are for you.
        
    • We're shipping source bundles. For the first time ever we're shipping source bundles for a J2SE release while it's under active development (gulp). This should make it easier for interested developers to contribute to the release as it evolves. In past releases the only ways to do that were to be lucky and know someone at Sun, or be lucky and have your suggestion survive the labyrinthine gauntlet of the bug-submission process.

        Posting source bundles will also make it easier for us to be embarrassed by our mistakes, but we're quite happy to be arbitrarily embarrassed in exchange for higher quality.
        
    • We're using java.net. One of the big goals here is to engage better with the developer community, and java.net provides excellent infrastructure for that. The bundles are being hosted in the overall j2se project, which will shortly acquire the other usual project accoutrements such as mailing lists and forums. We're also working on a streamlined process for patch submission so that you can send code directly to real live JDK engineers rather than paste it into a bug report, cross your fingers, and hope for the best.
        
    • We're using a new license. The source bundles are covered by the Java Research License. The JRL is, to my non-lawyerly brain, a big improvement over the old SCSL license -- for one thing, I can understand it! The JRL also gives developers and researchers more flexibility than SCSL did, though it's still not an actual open source license in OSI terms (sorry).

    Taken together these changes obviously entail a much bigger, and longer,
    experiment than the Tiger Snapshots. We certainly don't want to wait until the
    end to learn from the experience and make adjustments. If you have ideas on
    how we could do any of this better, please let us know!

    Read Mark Reinhold in Mustang Snapshots: Another experiment in openness

    Threaded Messages (32)

  2. From the J2SE project site on java.net:
    Please submit bugs against the snapshot releases via the usual channels. Be sure to include complete version information from the output of the java -version command.

    Too bad that bugfixes still go through the bug parade (thus still take ages ;-) ) and there isn't a place to submit your own fixes (atleast some repository that the J2SE developers can use; take out a fix, evaluate it, test it, copy it in).
    In terms of licensing, ownership and IP; I personally woulnd't mind to let Sun have all of it on the fixes that I'd submit.
  3. From the J2SE project site on java.net:
    Please submit bugs against the snapshot releases via the usual channels. Be sure to include complete version information from the output of the java -version command.
    Too bad that bugfixes still go through the bug parade (thus still take ages ;-) ) and there isn't a place to submit your own fixes (atleast some repository that the J2SE developers can use; take out a fix, evaluate it, test it, copy it in).

    From above, We're also working on a streamlined process for patch submission so that you can send code directly to real live JDK engineers rather than paste it into a bug report, cross your fingers, and hope for the best.

    That's part of the "experiment" in openness.
  4. I'm just glad there's a way to report bugs[ Go to top ]

    From above, We're also working on a streamlined process for patch submission so that you can send code directly to real live JDK engineers rather than paste it into a bug report, cross your fingers, and hope for the best.That's part of the "experiment" in openness.

    having submitted bugs in the past, I'd rather have a process that is long than none at all. Plus, from a developer perspective, more details helps me debug a problem. I don't mind filling out every detail, since it gives the developer more information to reproduce and fix the bug. Improvement in the bug reporting process would be good, but for me, it's second to having a detailed bug report.
  5. Wouldnt it be better first to tell what will be main features of Java 6.0.
  6. Wouldnt it be better first to tell what will be main features of Java 6.0.

    A big part of new Java 6 is improved Swing, based on JDNC!

    JDNC is excelent!!!!!!!!!!!!!!!!!!

    .V
  7. How about adding SWT in Mustang ?[ Go to top ]

    Instead of fighting between Swing and SWT, why can't sun
    add this API in JDK itself. Always sun says they want to give choice, there are lot of people out there who wants SWT also. Please provide that choice atleast in J2SE 6.0

    Regards,
    Ram
  8. How about adding SWT in Mustang ?[ Go to top ]

    Mustang will have something better than SWT in, JDNC!
    .V
  9. How about adding SWT in Mustang ?[ Go to top ]

    I don't want to fight here which is better. As i already told it's because of choice. I know swing is better in Tiger and it will be still better in Mustang. But, what is wrong in adding SWT also !

    Finally customer or developer wins. If developer or customers wants SWT ?

    Regards,
    R
  10. I don't want to fight here which is better. As i already told it's because of choice. I know swing is better in Tiger and it will be still better in Mustang. But, what is wrong in adding SWT also !Finally customer or developer wins. If developer or customers wants SWT ?Regards,R

    It is very wrong to keep adding stuff.
    What we really need is a repository and ability of J2SE core to download necessary library only ONCE on demand!!!!!!!!!
    That will speed up and simplify client side deployment, and help enormously client side Java.

    I think that Maven type repository should be adopted as is and right now.
  11. It is very wrong to keep adding stuff.What we really need is a repository and ability of J2SE core to download necessary library only ONCE on demand!!!!!!!!!That will speed up and simplify client side deployment, and help enormously client side Java.I think that Maven type repository should be adopted as is and right now.

    Such a way to do things it's very flexible from a developer point of view, but I think it raises a number of issues from the end-user point of view. Should the user mandatorily be connected to the internet while installing your software? Should the customer (imagine a a corporate environment) allow each employee to dowload piece of sofware from the internet without much control about it?
  12. It is very wrong to keep adding stuff.What we really need is a repository and ability of J2SE core to download necessary library only ONCE on demand!!!!!!!!!That will speed up and simplify client side deployment, and help enormously client side Java.I think that Maven type repository should be adopted as is and right now.
    Such a way to do things it's very flexible from a developer point of view, but I think it raises a number of issues from the end-user point of view. Should the user mandatorily be connected to the internet while installing your software? Should the customer (imagine a a corporate environment) allow each employee to dowload piece of sofware from the internet without much control about it?

    It is no different than allowing applets.
    As for corporate users: local version of repository can be bootstraped, or JRE can be configured to work with internal corporate repository only, etc.
  13. I don't want to fight here which is better. As i already told it's because of choice. I know swing is better in Tiger and it will be still better in Mustang. But, what is wrong in adding SWT also !Finally customer or developer wins. If developer or customers wants SWT ?Regards,R
    It is very wrong to keep adding stuff.What we really need is a repository and ability of J2SE core to download necessary library only ONCE on demand!!!!!!!!!That will speed up and simplify client side deployment, and help enormously client side Java.I think that Maven type repository should be adopted as is and right now.

    If it's wrong to keep adding stuff, we will be still in JDK 1.0 itself. If innovations happen in the technology, we should add it to the core. Period.
  14. If it's wrong to keep adding stuff, we will be still in JDK 1.0 itself. If innovations happen in the technology, we should add it to the core. Period.
    Sure: everything should be added to Unix kernel, no downloads are allowed. What a relief: no more DLLs/SOs/Plugin mess - just one monolitic core - hurraah!
  15. Nothing on JCP.org?
    No JSR for it?
  16. JCP?[ Go to top ]

    Nothing on JCP.org?No JSR for it?

    How's this: We'll bulid it best we can, and then JCP it.

    I need a comitte to help me code?
    .V
  17. How about adding SWT in Mustang ?[ Go to top ]

    Why should Sun add SWT to a JDK/JRE when SWT produced by a third-party?

    There is nothing stopping you or anyone else from adding SWT to your runtime.

    SWT is not as portable as Swing so it would kind of break "Write once, run anywhere".
  18. Why should Sun add SWT to a JDK/JRE when SWT produced by a third-party?
    Yes, Sun should not. But simplification of adding Sun's own and 3rd party stuff will not hurt.
    There is nothing stopping you or anyone else from adding SWT to your runtime.
    There is nothing prevent us from using ASM language or writing Java bytecode manually. Except inconvenience perhaps?

    Installation and lazy downloading should be simple and smooth: lets compare emerge/yast package installation with manual process. The difference - convenience.
  19. Maybe JRE have reached a point where it could be split into different "distributions", like server install (no UI-oriented libs at all), client install (some server-oriented libs left out), full install, and custom install (user chooses what libs we wants). And on top of that, allow for a webstart-like download of JRE parts: whenever some app requires a library not installed on local machine, it would "freeze" until this lib gets installed, and then continue. The JRE would be responsible for identifying when a particular lib is required but not installed, and guide the user towards having it installed, either from an internet download, or from a local network server, or local computer's drive... How about that?

    Regards,
    Henrique Steckelberg
  20. Maybe JRE have reached a point where it could be split into different "distributions", like server install (no UI-oriented libs at all), client install (some server-oriented libs left out), full install, and custom install (user chooses what libs we wants). And on top of that, allow for a webstart-like download of JRE parts: whenever some app requires a library not installed on local machine, it would "freeze" until this lib gets installed, and then continue. The JRE would be responsible for identifying when a particular lib is required but not installed, and guide the user towards having it installed, either from an internet download, or from a local network server, or local computer's drive... How about that?Regards,Henrique Steckelberg

    Excellent description of much needed feature.
  21. Please, please, wipe out AWT... it shames me in front of my colleagues... it's so rusted but it just doesn't drop dead!

    Swing is nice, but should become deprecated. SWT has proven to be a better solution. so it must be included.

    3 years ago I filled a RFE, asking for _decent_ HTML support in Java. My claims where never heard, so we still have HTML 3.2 in Java. Oh, I know that nobody had used it for years, but, hey.. come on... we're working on it, give me three more years... <?>

    Another addition for j6se that i'd like to see is, well, is kinda mistargeted, because it shold be an OS service, not at jvm level, but... could you plese support firewalled clients in the JVM so we don't requiere each application to be aware of it? Every single application needs to be aware of it.

    ok, enough for today...

    hielito
  22. Swing is nice, but should become deprecated. SWT has proven to be a better solution. so it must be included.
    How come? Where is the proof?

    It does not make any sense to fight for one OR another. Real solution should allow one AND others. JRE core support for repository will provide such a solution. So lets fight for it and then time will show what people like and use most.
  23. Swing is nice, but should become deprecated. SWT has proven to be a better solution. so it must be included.
    How come? Where is the proof?It does not make any sense to fight for one OR another. Real solution should allow one AND others. JRE core support for repository will provide such a solution. So lets fight for it and then time will show what people like and use most.

    No need to scrap swing. It's better if we can support both.
    What SWT has proven is we have to utilize the native capabilities of GUI and lets leave to OS vendor to enhance the GUI in future. SWT will have all common widgets that all platforms support.
  24. Feture[ Go to top ]

    I think Java auto update is important to make deploymaent easy.

    API is bavkward copatible.
    So if users have 1.4.2 and click update now, they get 1.5 and so.

    Same as in windows update, or how most applications have:
    "A new version of Java is available, do you want to update?"

    Sort of WebStart for Java itself.
    .V
  25. How about adding SWT in Mustang ?[ Go to top ]

    Why should Sun add SWT to a JDK/JRE when SWT produced by a third-party?

    xerces, and log4j come to mind, though sun really managed to munge the logging implementation up horribly causing the need for a third party abstraction layer (commons-logging).

    with xerces (or was it xalan?) in 1.3 every app needed to have it's own version of these libraries that they could depend on. then moving to jdk 1.4 would sometimes break this since the jre included this stuff by default at a fixed version that was cumbersome to over ride and even then i don't think each app could choose which version they wanted to use.

    why should they add third party software indeed.
  26. How about adding SWT in Mustang ?[ Go to top ]

    I read that the swing group it's considering some form of platform delegated rendering to improve the fidelity of the L&F.
  27. This step is really welcome (at least from my side, but I guess from a lot of other developers too) and I know this is just the first and very early release.
    However, currently, I cannot find a "ChangeList" documentation (didn't download it yet, is one included?), which would be very important (online, so I can check before downloading & extracting/installing).
    I also wonder what Sun's developers are currently working at, as there doesn't seem to be a JSR for Mustang yet (?), at least not publicly available (I hope an extended Generics implementation, i.e. VM support, will be included).
    Does anyone know what is planned for Mustang?

    kind regards,

    Messi
  28. Thank you[ Go to top ]

    I'd like to add my voice to those saying thank you for this new more open process. I also look forward to the more open bug submission process.

    It will be important to provide some kind of ongoing list of changes, perhaps grouped by package, so people can see what changes are going on in each release drop.

    It will also be important to communicate the themes of the release - is it more language changes, or more library tidying?
  29. Javadoc please......[ Go to top ]

    I can get Javadoc for JDNC here:
    http://jdnc.dev.java.net/files/documents/1746/8515/jdnc-0_6-2004_11_04-doc.zip

    But... where is the Javadoc for Mustang please?
    Building source there looks like 12 steps.

    I CAN'T get over the huge turnaround at Sun.

    If somone knows hot to get Mustang Javadoc, help!
    tia,


    .V

    ps: I will post a sample RiA/SoA app using Mustang and Html editor. He, he, he.
  30. My first wishlist[ Go to top ]

    I would just love it if Java had:
    1. Version management of jars. I'd love for the jar manifest to describe the version of the jar (what version it is and what versions it is compatible with) as well as the requirements for jars it is dependent on (kind of like an RPM). Then get the class-loader to allow multiple versions to co-exist and be resolved correctly.
    2. A compiler flag to allow packages to be renamed. Then JBoss, Tomcat, Weblogic, etc. can use org.apache.whatever to their hearts content and rename them so they don't clash with what the application wants to use.
  31. Just a thought[ Go to top ]

    Maybe now we can have a method to get free disk space :)
  32. Is it possible to break down the JDK in different jars (core, swing, etc.) and also have version with and without deprecated code?
  33. We at Zamples took advantage of Sun's new openness and proudly bring you Live Code Examples for J2SE 6. Right now we have build 14 installed. We will keep the version in step with what is available from java.net. Please post any cool new features you discover!