Showing messages 1 through 42 of 42.

• Enhanced switch .. case usage
  2007-01-24 14:47:32 ulfzibis [Reply | View]
  
  See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5012262

• wish the default encoding of .properties file set to UTF-8
  2007-01-24 08:52:14 lovetide [Reply | View]
  
  instead of current ISO-8859-1

• None of the above ...
  2007-01-24 05:43:19 arae [Reply | View]
  
  but a few minor fixes would be nice like chdir or ability to see windows' special keys. And generic arrays.
  
  Give me operator overloading before closures.

• None of the above ...
  2007-01-24 05:42:26 arae [Reply | View]
  
  but a few minor fixes would be nice like chdir or ability to see windows' special keys. And generic arrays.
  
  Give me operator overloading before closures.

• Isolates in Java7
  2007-01-24 02:32:52 jhm [Reply | View]
  
  I would like to see Isolates in Java7 so that multiple applications could share the JVM.

• Multimedia Support
  2007-01-23 16:53:58 adamadas [Reply | View]
  
  JOGL and JOAL are becoming more and more famous and more application appear to me oriented on these APIs... Why not embedded in JDK7?

• I want ALL features
  2007-01-23 06:39:53 vigor [Reply | View]
  
  VERY VERY MUCH !!!!!!!
  They are all so sweet !!!!!!!!!!
• I want ALL features
  2007-01-24 09:08:24 jeveloper [Reply | View]
  
  I agree
  All features are cool and much anticipated.
  :))
  
  Java rules

• handing control to ISO
  2007-01-21 22:47:50 jwenting [Reply | View]
  
  That way the marketing boys at Sun can no longer add "features" to the language for no other reason than that C# (or Ruby, or Python, or VB, or Delphi) has them and the language may finally settle down into a reasonably stable state where you know one day what the language you're working with will look like the next.
• handing control to ISO
  2007-01-22 09:46:52 tompalmer [Reply | View]
  
  Hmm. C# is an ISO standard.
• handing control to ISO
  2007-01-22 09:49:40 tompalmer [Reply | View]
  
  (Note that I'm not saying Java should have every C# feature. There are several things in C# that I think are redundant, unneeded, not-Java-like, or just plain wrong. But that doesn't mean I think it's all bad. It also doesn't mean that it's not an ISO spec.)
• handing control to ISO
  2007-01-24 01:58:52 jwenting [Reply | View]
  
  Nor am I saying everything in C# is bad (in fact I like the language). But Java is being swamped with "features" that are added for no reason other than that some other language has them. There is no longer a process to determine if there's any real use or value for something it seems, if C# (or Ruby, or C++, or whatever) has it, then so should Java.

  In contrast C++ (for example) is developed as a language with far more thought, at a deliberately slow pace in order to assure that only things that are of actual value make it into the language.

  I've no problem with things making it into the language, but they should have real added value above (or maybe instead of) making for nice marketing slogans. "Now new and improved, with embedded XML support!!!", "now with embedded database, get it while it's hot!!!!!", "no more need for expensive application servers, full SOAP stack built into the core installation. Save NOW!!!!!".

• Swing Databinding and application framework
  2007-01-21 16:27:52 dstaelen [Reply | View]
  
  I would like to see strong effort in the Swing data binding and application framework that Hans introduced at last years Java One.
• Swing Databinding and application framework
  2007-01-23 06:12:27 swpalmer [Reply | View]
  
  I've been waiting to see what the databinding group has come up with for a long time now. My company donated a chunk of code to them from our own framework but I don't know if Sun's lawyers ever let them look at it.

• Please don't clone C#!
  2007-01-21 07:36:50 pjmlp [Reply | View]
  
  When Microsoft launched .Net I was working at a company that was working on the beta version.
  
  My feelings towards C# changed from "Another Java clone" to a language that has its place. At least on the Microsoft world.
  
  Now please, don't make Java an schizophrenic language by reimplementing all C# features, just with another syntax.
  
  We do have more things to worry about like improving the JVM, the multimedia support, bluetooth, USB and so on.

• Closures pave the path for Native Queries
  2007-01-21 06:40:08 carlrosenberger [Reply | View]
  
  With closures it will be possible to write Native Queries like the following:
  
  List cats = db.query( { Cat cat => cat.getName().equals("Wolke") } );
  
  This way Java has an answer to LINQ.

• Developers vs Users
  2007-01-21 01:20:38 dannyor [Reply | View]
  
  Pity that better multimedia support did not get more!
  I think that features that imply better user experience and/or features that make it easy to write better applications, that may compete with applications created with other technologies, are far more important than features that are more developer oriented. What is the point of having a wonderful language if no one uses it. If your application relies on heavy use of sound (like multi track audio editing) and/or video (like video editing), would you use Java?
  
• Developers vs Users
  2007-01-23 06:16:15 swpalmer [Reply | View]
  
  I voted for multimedia improvements as well. I work on a Java UI for a high-end video encoding application. I would also like to see better support for image capture devices like scanners and cameras. Support for Faxing directly from Java. And, of course, JMF done right and completed.
  
  JMF had so much promise when I first spotted it, but it never matured. If you've ever used Microsoft's DirectShow you know how poorly it can be done. JMF could have been a great thing.
  
  
• Developers vs Users
  2007-01-22 07:16:15 sasdav [Reply | View]
  
  If I wanted it to be cross-platform I certainly would.

• multiple applications in the same jvm
  2007-01-19 15:13:36 ga24 [Reply | View]
  
  Taking the broad view of Java, that is, including the JVM, by far the single biggest current deficiency in Java, IMHO is the lack of the ability to run multiple applications in the same JVM (robustly, efficiently, of course).
  
  In other words, implement JSR 121 and JSR 284, but with JSR 284 explicitly including memory as a managed resource in JSE.
  
  And include an option to start the JVM at boot time, and the ability to have multiple JVM's, each with multiple applications, for separation where needed.
  
  I really surprised nobody else has mentioned this.
  
  The inclusion of scripting languages in Java, that is, another category of small programs, makes this more pressing.
  
  Applets will always be perceived as slow until this is done, and, when it is done, the perception will be reversed: they will be perceived as very fast.
  
  Startup time (if the JVM is loaded at boot time) will be ZERO, and the memory footprint will go down, since there will be only one JVM, typically. The class data sharing work is great, but this is needed to go the rest of the way.
• multiple applications in the same jvm
  2007-01-22 07:23:09 weberjn [Reply | View]
  
  I second that.
  
  Also this could lead to Java being useful as system programming tool. You could do that little tools in Java that take way too long to start up in Java now and need C or Perl or scripting.

• multiple applications in the same jvm
  2007-01-19 15:12:59 ga24 [Reply | View]
  
  Taking the broad view of Java, that is, including the JVM, by far the single biggest current deficiency in Java, IMHO is the lack of the ability to run multiple applications in the same JVM (robustly, efficiently, of course).
  
  In other words, implement JSR 121 and JSR 284, but with JSR 284 explicitly including memory as a managed resource in JSE.
  
  And include an option to start the JVM at boot time, and the ability to have multiple JVM's, each with multiple applications, for separation where needed.
  
  I really surprised nobody else has mentioned this.
  
  The inclusion of scripting languages in Java, that is, another category of small programs, makes this more pressing.
  
  Applets will always be perceived as slow until this is done, and, when it is done, the perception will be reversed: they will be perceived as very fast.
  
  Startup time (if the JVM is loaded at boot time) will be ZERO, and the memory footprint will go down, since there will be only one JVM, typically. The class data sharing work is great, but this is needed to go the rest of the way.
• multiple applications in the same jvm
  2007-01-19 23:53:46 aehrenr [Reply | View]
  
  What if two applications run in the same JVM and one has native code and this native code crashes ?
  Do you remember Win95 or MacOS9 ?
  How to prevent that a crashing application brings down the whole JVM with all applications?
• multiple applications in the same jvm
  2007-08-22 07:36:51 ga427 [Reply | View]
  
  That was what was alluded to in the "robust" qualifier.
  
  see Chet's blog on the topic (in the commentary section)
  
  http://weblogs.java.net/blog/chet/archive/2005/06/mmmmmm_vm.html
  
  Briefly: there are two scenarios: native code in the JDK, and other native code:
  
  1. Native code in the JDK, after all this time is pretty reliable, call it without protection - no changes needed.
  
  2. For other code, add isolation logic to protect things (which adds overhead, lets be clear) so that a failure can be captured and the offending program notified/shut down. In some implementations this may be as simple as a signal to another process to pick up a payload and run it.
  
  This needs to be turnoffable - there needs to be an option to run boldly without this (assuming there is some overhead cost worth avoiding).
  
  The big problem with all of this seems to be that it is changing the plumbing in a major way, thus the risk/reward analysis reveals heavy risk. I, personally, thing the reward is sufficient, so I say, let move now, and add this as a default-off feature.
  
  This is easy for me to say, since I'm not doing the work and won't be taking support calls if something slips through :)
  
  Glenn
• multiple applications in the same jvm
  2007-01-21 02:39:03 fabriziogiudici [Reply | View]
  
  If I'm not wrong, the single-JVM approach is effective in Mac OS X for years now and it's stable - a crash in a single application doesn't affect others for what I can see.
• multiple applications in the same jvm
  2007-01-21 08:18:42 aehrenr [Reply | View]
  
  The mac starts every JVM as a new instance. Jars used by several programs are loaded only once in the memory, just as shared libs in the native world. So e.g. the Swing classes are loaded only once in the memory which reduces the memory footprint, but this is not a single JVM running multiple programs! If I remember correctly, this is already implemented in JRE 5 by Sun too. The advantage of the Mac is that it has a single JVM installed (OK, to be correct, two versions). And during updates this JVM gets updated. This is much better than the Sun appoach with dozens of old JVMs on a typical computer. During an update you just add another one to the chaos. But all your Java apps remain linked to the old JVMs, so the update dosen't buy you anything. Yes, please Sun, improve this situation with Java 7.

• parallel processing
  2007-01-19 14:24:07 dog [Reply | View]
  
  I'd like to see better support for symmetric multiprocessing and for vector based operations. We're entering the multiprocessing era and our languages need to adapt.

  Maybe transactional memory support?

  None of these other things seem at all important to me.

• Runtime generics support
  2007-01-19 14:13:14 prunge [Reply | View]
  
  I'll have to vote #1 as runtime generics support, but the new module system comes in at a close second.

• Erase Erasure
  2007-01-19 11:58:50 weiqigao [Reply | View]
  
  My biggest wish for a future version of Java, not necessarily Java 7, is to have the other half of Java generics (runtime support for generic types) implemented, thus remove the need for erasure.
• Erase Erasure
  2008-02-19 23:37:09 duybvo [Reply | View]
  
  Absolutely!!! This is at the top of my wish list!

• Verbatim Strings
  2007-01-19 10:20:28 joeys [Reply | View]
  
  It would improve readability if the String “” could span multiple lines so that when embedding foreign language like SQL the developer would not have to break up the String with + operator. This would also make it easy to cut and past code back and forth between an SQL editor.
  
  Regular expression would be a lot easier to read to. The expression “\(\s+\)” would not need to look like this. “\\(\\s+\\)”
  
  C# does something like this with the @ symbol. Something like @” ”
• Verbatim Strings
  2007-01-19 11:16:24 tompalmer [Reply | View]
  
  

  One thought I've had for syntax in Java is to prefix the string with \. Seems related, doesn't overload the meaning of @ (which has a different meaning in C#), and it shouldn't conflict with separate oddness like Unicode character literals because of following characters. So for example:

  \"\(\s+\)"

• I hope Sun is paying attention
  2007-01-19 10:03:23 sasdav [Reply | View]
  
  The most popular choice is improved multimedia support. It's something that is very important to developers and mostly ignored by Sun. Yes yes, I know all about JMF. Java Media Framework just confirms my point. Nothing has been done with JMF in over two years. It's time to either support multimedia or not. Sitting on the fence isn't enough.
• I hope Sun is paying attention
  2007-01-20 00:38:25 xodox [Reply | View]
  
  I totally agree.
  
  I think a great way to go would be doing an integration to a native backend available on the system, much like Phonon(http://phonon.kde.org/) - we could perhaps even use Phonon.
  
  Java should not have its own set of codecs. It should have the native system's codecs - allowing fx. all gstreamer decoders to be used on Linux.
• I hope Sun is paying attention
  2007-09-06 01:06:28 defrector [Reply | View]
  
  I respectfully disagree in part.
  
  A possible snag is if a proprietary (by one definition or another) codec is used on, say, a windows machine, but there is no version of that for Linux or Mac OS X (or the Wii or your wristwatch,etc)-although it seems like it would be a liberation to hand control to the OS regarding codecs as far as quanitity goes, the reliability between platforms would be at risk of getting shaky as now the codec developers have to do Sun's job, making a codec for every native platform. The issue would arise when some of these developers choose not to do that.

• Why just one favorite?
  2007-01-19 08:36:42 tompalmer [Reply | View]
  
  

  I voted improved multimedia support, but close seconds for me (from this list) are closures, resolution-independent Swing, and USB support. Personally, I like the not-null support thing and better properties, too. But I'd them after my above list.

  I'd also like to see HotSpot support immediate Integer objects (or more clever since the JVM is strongly typed) for higher-performance support of purely object-oriented languages. To give more detail, this is the trick where you know (for some CPUs) that all pointers are on 4-byte boundaries, so you cheat with the extra bits as flags to store immediate values and pretend they were pointers.

• Why just one favorite?
  2007-01-19 08:58:01 tompalmer [Reply | View]
  
  Oh, and I also want instant start-up time, so we can finally start writing shell-level scripts in Java and JVM-based languages. (It does seem to have improved in Java 6 some, already?)

• Most important: A versioning strategy
  2007-01-19 07:01:18 aehrenr [Reply | View]
  
  Beside XML support or properties I want them all :-).
  But I think most important is a kind of comprehensive versioning support that should build on the module system.
  It would have to be a smart system so that it becomes possible to bundle older versions of libraries and newer ones. Older programs automatically link to the older version, newer programs to the new version. Then it would be possible to refactor or improve the APIs. Imagine, Swing could use enums, support Closures, the Date class could be fixed and so on.
  If the whole thing is really smart this should also allow the language to be improved without complete backward compatibility of the source: One can specify the compiler the 'incarnation' of the language to be used and code converters in the IDE point to conflicting sites in the source that have to be modified to upgrade or downgrade 'incarnations'. A 'incarnation' is a range of versions that are source compatible.
  This would allow clean implementations of new features (e.g. new keywords) and the removal of old ones. (e.g. closures in, anonymous inner classes out)
  While you are at it, improve the class format to fix inner classes support and runtime representation of generics.
  Altogether this would be a strategy for Java to stay young, because old things can be left behind, but old programs still run and old libraries can still be used and old source still be compiled.

• Protection agains NullPointerException
  2007-01-19 06:54:27 christian_schlichtherle [Reply | View]
  
  Something like C++ references, for example. I don't mind the particular approach, but I would love to see a solution.
  
  Why?
  
  Generics where said to solve ClassCastException. But ClassCastExceptions aren't a problem for me. NullPointerExceptions are a plague however: There's hardly a day without a NullPointerException in either foreign code or my own code. If some means to extinct this issue would exist, then probably 80% of my trouble would be gone.
  
  Regards,
  Christian
• Protection agains NullPointerException
  2007-01-24 13:24:38 artti [Reply | View]
  
  Null-safe variables would be great.
  
  I think Nice language has a good syntax:
  
  ?String nullable; // has to be checked for null before use
• Protection agains NullPointerException
  2007-01-19 07:26:39 scolebourne [Reply | View]
  
  I've talked about a language change to fight NPEs on my blog.

• Introspection for lists
  2007-01-19 06:36:50 lucasjordan [Reply | View]
  
  so you can tell what types of objects are supposed to go in them at runtime. As a tool builder, I find the fact that you can't do this makes simple problems a real pain in the ....