Slashdot Mirror

← Back to Stories (view on slashdot.org)

New Desktop Features Of Next Java

Posted by Zonk on from the cuppa-joe dept.

bonch writes "Sun has posted the new desktop features of the next Java, codename Mustang. Improvements to Swing look and feel, OpenGL 2D renderer performance, AWT features such as the ability to add a tray/panel icon, and improved deployment capabilities."

22 of 283 comments (clear)

  1. Additional items by BWJones · · Score: 1, Interesting

    Here are my items that I would like to see in the next Java:

    1) The ability to allocate more memory space to Java apps.
    2) 64 bit support.
    3) Ability to/Easier implementation of hardware specific calls to speed calculations. (e.g. Altivec acceleration).

    --
    Visit Jonesblog and say hello.
    1. Re:Additional items by Anonymous Coward · · Score: 1, Interesting

      2) 64 bit support.

      Hard to see how to improve that without destroying run-anywhere. You'd have to stick with 32-bit integers, or you wouldn't get the same behaviour on two different platforms. I guess the VM could use 64-bit pointers internally, but as you can't access memory directly in Java I don't know how the programmer would ever be able to tell.

      3) Ability to/Easier implementation of hardware specific calls to speed calculations. (e.g. Altivec acceleration).

      This should be implemented at the VM level. Exposing this kind of hardware detail to the programmer would completely miss the point of using a VM in the first place. If you really want to limit yourself to a single platform, use JNI to call C code that uses your hardware-specific instructions. But if you're going to do that, why not just use C++ in the first place?

    2. Re:Additional items by lawpoop · · Score: 2, Interesting

      I don't get it. If sun was responsible for 64-bit computers being commonplace, how come Java doesn't support 64 bits?

      --
      Computers are useless. They can only give you answers.
      -- Pablo Picasso
  2. It's worth noting... by AKAImBatman · · Score: 5, Interesting

    ...that mustang is also the first Java version to be developed under an Open Source type model. The CVS is open to guests over on http://www.java.net, thus allowing for immediate feedback and bugfixes. It has been a real boon for the gaming community, as they've been able to direct several key performance features.

    --
    Javascript + Nintendo DSi = DSiCade
  3. The look and feel of Swing. by chkorn · · Score: 3, Interesting

    Yeah! This is really something that should be made better.
    Always when I use some Swing based applications I'm remembered that the times of ugly GUI's aren't over yet.

    --
    chris
    1. Re:The look and feel of Swing. by TiMac · · Score: 3, Interesting
      They are improving the Windows and GTK Look and Feel...but I'm hoping also that either Sun or Apple tackle the Mac OS X look and feel of Java apps.

      Sure, you can code Cocoa apps in Java and use Java in those ways...but pure Java executables programmed in Swing still lack the complete purity of Mac OS X. Apple ships tools in the Developer Tools to improve Java (like Jar Bundler) but the UI still isn't perfect.

      --

  4. SubPixel Rendering by aCapitalist · · Score: 5, Interesting

    It looks like they've finally addressed this issue, but I think Sun is a little late.

    Personally, I can deal with non-native look-n-feel, but when the fonts look like something circa 1988 on an Amiga, how can anyone take Swing seriously.

    I never understood why they couldn't use platform specific code for fonts, and if not possible then go into fallback mode and paint everything themselves.

    Swing has been a disaster. I believe it was the OTI guys (who now work on Eclipse and SWT) that told Sun not to go the route of "give me a handle to a brush and we'll paint everything ourselves", but some other group won that debate.

    And thank god for .NET/Mono being around to give Sun a little kick in the rear to get moving on things.

    1. Re:SubPixel Rendering by Anonymous Coward · · Score: 1, Interesting

      SWT seemed like a good idea at the time but overall it's time has past.

      Swing is fast now (and has been since early 1.4.2 releases) and the few areas where it is not quite up-to-snuff are rapidly being fixed.

      Overall, SWT seems like a waste of good developers' time -- both those who wrote it and could have been writing something of more lasting use and those who bother learning it and splitting Java GUI mindshare.

    2. Re:SubPixel Rendering by bnenning · · Score: 3, Interesting

      Swing has been a disaster. I believe it was the OTI guys (who now work on Eclipse and SWT) that told Sun not to go the route of "give me a handle to a brush and we'll paint everything ourselves", but some other group won that debate.

      Indeed. The implementation of AWT sucked, but it at least had the right idea: the host OS has facilities for drawing interface elements, so use them rather than reinventing the wheel. Apple's Swing L&F is halfway decent because they use native APIs to draw widgets, and according to the article Sun is now doing the same thing for Windows and Linux. Desktop Java would be in a much better state if they hadn't gotten sidetracked for years trying to make apps on every OS look identically bad.

      --
      How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
    3. Re:SubPixel Rendering by shutdown+-p+now · · Score: 2, Interesting
      I believe it was the OTI guys (who now work on Eclipse and SWT) that told Sun not to go the route of "give me a handle to a brush and we'll paint everything ourselves", but some other group won that debate.
      Strictly speaking, this approach can work very well. That's exactly how Qt handles things - and it's damn hard to tell a Qt app on Windows from a native one (not sure how things are on Mac, but judging by the screenshots, it's fine there as well).
  5. Disclaimer on the url "we would LIKE to" have in.. by Assmasher · · Score: 2, Interesting

    ...the next version.

    Not quite the same thing as "this is in the next version."

    --
    Loading...
  6. SWT by Yag · · Score: 1, Interesting

    Java must embrace SWT and start doing GUIs in a fast, portable, native way. SWING is slow, redundant and ugly. IBM knows the right way, SUN should follow them or surrender to .NET (both windows and mono have NATIVE widgets stuff).

  7. Re:JAVA - the little train that could by hanshotfirst · · Score: 4, Interesting

    And how long did it take BASIC to get this?
    When is it coming out for FORTRAN and COBOL?
    10 years is still young as far as languages go.

    --
    Why, oh why, didn't I take the Blue Pill?
  8. Sounds great...couple more things... by Anonymous Coward · · Score: 1, Interesting

    Those all sound like very good enhancements. I would get rid of the crappy "Ocean" theme for the default. It's really no better than the much hated Metal. It sounds like they have worked to get the native look and feel much improved, but I would still like to see a *much* nicer default since it seems like that's what so many developers end up using.

    The other thing is major Java Web Start improvements. I've tried to use it and it sucks majorly. Basically you end up having two different versions of your application, one that works with WS and one that works as a native application, which stinks from a QA perspective. Furthermore, while I know there are major security considerations when clicking on a program from the web, something has to be done about the dialog boxes. My own parents wouldn't run the application I wrote because it said "it is strongly recommended not to run this program". Then, there are all sorts of other weird dialogs like "would you like to enable desktop integration" that never works, and also sometimes gets put behind the application so you can't see it while it's still modal.

    Otherwise, they REALLY REALLY need to get a better browser component. Here's what I suggest:

    http://jrex.mozdev.org.

    Make this a part of the standard JRE! *It will be the most significant and best single thing that ever could have been done to java*. Imagine having a gecko rendering engine whose DOM is fully controllable from Java on every major platform that the JRE supports! Imagine being able to use a gecko widget inside any GUI com\ponent! That would be how to step up and really innovate.

    Finally, provide better desktop integration. Interact with the system tray. Allow "always on top" behavior. Include proper fonts (which it sounds like they're doing).

    All in all, though, it sounds like there are some definite improvements, but they need to leap frog, not just catch up. Taking the JREX.MOZDEV.ORG concept and running with it is just how to do it.

    1. Re:Sounds great...couple more things... by mccalli · · Score: 2, Interesting
      Basically you end up having two different versions of your application, one that works with WS and one that works as a native application, which stinks from a QA perspective

      Why? I'm genuinely curious here - I also use WebStart, and I don't need to end up with two versions of the code. Be interested to hear what's restricting you.

      Cheers,
      Ian

  9. Seems like they are really improving things by FedeTXF · · Score: 4, Interesting

    I use many java desktop apps in my day to day tasks on my linux desktop. There is no better way to connect to multiple databases than Squirrel , No better way to code in Java than NetBeans and no better editor than JEdit

    I think Java 5 already has great desktop features like shared class data, and 2D acceleration for 2D acelerated hardware (which I don't have yet!).

  10. Just checked out the latest build release by Anonymous Coward · · Score: 1, Interesting

    I just checked out the latest build release of Mustang, Swing at least on Win32 seemed again snappier, the absence of the gray rectangle problem really made a huge difference, the guy now is faster on Windows (tested it on SwingSet2 and JEdit) than Firefoxs is.

    But there still were minor annoyances in the Windows look and feel, mainly, the menus still are different to those done by windows (XP does dropshadows and transparency while being opened, Swing is flat) The file open dialog still has layouting differences, but besides that things start to look very good and fast. Cannot speak for Linux however and the Mac has yet to get a 1.5 release.

  11. Re:Java Desktop by MemoryDragon · · Score: 3, Interesting

    Actually Sun is not throwing in the towel, Swing has done an interesting approach no other Widget set has done so far. They basically went the way, of rendering the widgets still in software, but the underlying graphics layer is hardware accelerated if possible and the rendering data for the skins is directly parsed from the underlying OS skinning engine if present.

    And Swing has gotten much faster that way. Swing has been already more than usable in 1.4 and I recently checked the latest 1.6/6.0 builds, and all I can say is wohaaa... The guy in 1.6 at least on Windows is very snappy. I have had running Firefox and SwingSet2 running side by side and SwingSet2 blew firefox away rendering speedwise.

  12. What about XUL type layout? by Anonymous Coward · · Score: 1, Interesting


    I wonder why they aren't having an XUL/XAML implementation?

  13. What I want by ToasterofDOOM · · Score: 3, Interesting

    Is stability, security, and more speed. OOo 2 beta is SLOW and most issues i have with it are Java related in some way.

    --
    I am Spartacus
  14. I knock my pipes out writing SwingWT... by bobintetley · · Score: 4, Interesting

    ...and nobody bloody cares or remembers.

    SwingWT is a FREE implementation of the Swing APIs on top of SWT so you get all the juicy nativeness of SWT and all of the nice APIness of Swing.

  15. This doesn't work by Anonymous Coward · · Score: 1, Interesting

    Since Swing is much larger and more complicated than SWT/JFace this cannot technically be accomplished for REAL LIFE Swing applications. The reverse however is possible there is a partial SWT implementation running on Swing....
    Features such as full component based renderers/editors with truely decoupled models just can't be accomplished natively.