Language,Bugs,Documentation,Webstart,Application Stack, + Lots
#1 - Language Enhancements - NON REQUEST - I would ignore language enhancements. While possible language enhancements are 'nice', they will make support for them in tools and IDEs more difficult/complex. Granted that there may be some language enhancements as worthwhile as generics and annotations but I'm sure that JDK5 is enough for now. AspectJ, multiple return statements, Destructors, whats the point. If it survives a JCP then great...
#2 - Web Start - Web Start must be ROCK SOLID. There must be MASSIVE improvements. I cannot stress this enough. I would even push this for JDK 5.1. If a feature enhancement forum for JDK 5.1 was opened, this would probably rock up as the #1 request.
#2.1 - Web Start - I've also found that if I download an unsigned app from two different servers, it downloads it twice even though its exactly the same (not good). I sometimes want an application to run inside a web start enforced security container even though it is signed. For now, I use unsigned applications because I want them to run inside a security container.
#2.2 - Web Start - Include the possibility for the manifest of a standard application to list a remote library. The Java Runtime should have webstart load the remote runtime and the library should be loaded into the JVM inside a runtime enforced security manager. The Runtime should also manage multiple versions of the same library to ensure that two different applications which require JARs of different versions for different applications are preserved.
#3 - Documentation - I've mentioned this elsewhere. Javadoc can support many more very usefull artifacts that are not directly related to an API but are usefull to embed inside the source code.
#3.1 - Documentation - Some sort of common bundling mechanism or layout standard should be agreed upon for merging documentation, articles, HOWTO, FAQ, etc.
#3.2 - Documentation - Consider jdocs.com. With (#3 above), It would be easy to create something like a 'Java Technology Developer Network'. I personally think java.net should have been pushed along the lines of jdocs.com hosting quality documentation from other sites as well as original articiles submitted to java.net. Submitted documentation should be peer reviewed before being hosted and meet certain quality standards. Furthermore there should be a certain level of advertisement and feedback for 3rd party sites (eg: javaworld, javaalmanac and javapractices) that contribute their original articles to java.net. I feel its bad for the community to centralise documentation at the expense of the many developer sites but I think that there is such a variety of quality information that is hidden or difficult to find that it's bad for the community to _NOT_ centralise the quality information. Imagine, Javapractices.com + Javaalmanac.com + jdocs.com + ootips.com in a single site. My god it'd be good. A single site that you can point newbies to. In MS land this is known as the MSDN.
#3.3 - Documentation - java.net should have been used a bit better than it is now. Some of the projects hosted should be in sourceforge instead of on java.net. Java.net is real estate that could be better used as the Java Technology Developers Network.
#4 - Bugs - Go through the whole of bugtracker and remove and solve the simple bugs. (Really)
#5 - Swing, SwixML - I like the idea of SwixML and XML swing interfaces included in the JDK. The problem is that I'm not sure I like the idea of the JDK exploding. When someone says 'include product X in the JDK', what they're really wanting is a (a) certain level of security that the product is not going to 'disappear' and that (b) its actively developed where certain critical business related issues are actively solved and (c) the only dependancy is the JDK instead of many other libraries.
#5.1 - Application Stack - What I would like to see is a certified J2SE application stack. A set of components that are not necessarily authored by SUN but whose version is critiqued by the community and included in a frozen 'application stack'. I would definately like SwixML to be included in this stack. A possible process to upgrade this would be to have the original propose valid extensions to this component, whose extensions are again critiqued and then included in the next version of the JDK.
This differs slightly from the interface view that Sun and the community likes to follow where they define standard interfaces and other companies provide standard implementations. If the original author of SwiXML could justify and specify his implementation to such a level (for example), it might be possible for other developers to implement an SWT provider for his component.
I'd like a SwixML/XML-layout mechanism to be included but I dont want the JDK to explode. Included in this 'application stack' would be libraries like Java Help. They'd be developed and maintained as a single project (like J2EE and J2SE) instead of lots of individual projects.
#6 - Swing Action framework - There is a right way to tie a large swing application together with actions and there is a wrong way. I'm sure IntelliJ have got this figured out and I am sure that many people do things the wrong way. In a small app, everything is easily developed and easy to manage. When a swing application explodes in size, development becomes fractured unless things are very restrictive or a framework is well planned. Support for a plugin framework, modules, context sensitive popups on JTrees, JLists, dynamically expandable JTrees, long running activities, SwingUtilities.invokeLater, etc.
#7 - Swing Layouts - Review community apps and figure out what other layouts are required to ensure that no developer has to rewrite their layouts unless they have fundermental layout needs. Net Beans and IDEA IntelliJ both have their own layout needs that go beyond the current layout mechanisms for simplicity. While I dont advocate 'special' support for any particular tools, their development course highlights a deficiency in the current distribution.
#8 - RMI - RMI can be improved. Alot of enhancements have been requested in the bugtracker. I'm not keen on the current mechanism of having 101 parameters passed in over the command line/environment to control RMI setups. Review AltRMI and other RMI implementations. Support advanced, but fundermental, issues like having objects explicitly bound and exposed over multiple ip ports (or channels). Objects are currently exported over RMI on a particular machine port. RMI currently includes support for RMI over HTTP. This mechanism should be refactored out into seperate channel architecture.
#9 - Commercial Application Stack - Buy or cross license a certain set of commercial applications that provide complete coverage of certain development tools that are not part of the major J2EE enterprise stack. Tools like a JAR to EXE converter, Install Anywhere, IntelliJ IDEA, Atlassian JIRA, advanced COM+ components, additional Swing Sets, etc. These should be provided as some sort of SUN Commercial Application Stack and is comprised of a variety of components not necessarily developed by SUN. Sun improves the community, the community improves Sun. The key point is that a company like the one I work for (MS biased) can license a single bundle. They ask 'What can I license from SUN that'll give me everything I need?'. At the moment we get the MSDN license for each developer whereas we have to motivate for each individual tool in the Java world. Once again, I dislike Sun trying to 'bottle' the community (as in #3.2 above) but I think it would be benificial for something like this.
#10 - JNI - Make JNI _ALOT_ easier to use. I cannot stress this enough. If JDK5.1 were to be released, I'd ask that JNI be enhanced. The following thread has some great ideas: http://forums.java.net/jive/thread.jspa?threadID=112&tstart=15
#10.1 - uint - Compiler and/or JVM support for unsigned byte, unsinged short, unsinged int and unsinged long (ubyte, ushort, uint, ulong). By compiler support, I mean automatic "byte b = 0xFF & x" (where x = int x). When it comes to better JNI integration, I think its just plain silly that there is not unsigned support. Unfortunately I dont know how this could affect the JVM, but I think its just plain silly without these. I do see it a bit pointless to have a whole additional set of instructions for byte level manipulations. Maybe this request is the wrong solution, but there has to be a better solution than to using 0xFF & b when working with bytes to set the value 255 to a byte.
#11 - Deprecated - Remote alot of cruft and many deprecated functions. I sometimes see Enumeration and Iterator. Now... are both needed? I see a List with Vector as a constructor. I can understand a List as a constructor, and even Collection but not Vector. I sometimes wonder whether the synchronised list is the need. Iterator could extend off Enumeration and method names could be renamed. Iterator and MutableIterator. Immutable Date and other immutable objects, etc. SwixML requires certain swing constructors changed. While it might seem that it is reasonable for Sun to change its constructors for a single app, their need shows a deficiency in only some swing components and possibly others.
#11.1 - J3SE - Something like #10 would possibly break a large number of applications. I still expect there to be a J3SE at some point in the future. If the major breaking release waits until J3SE then sure.
#12 - Date - Besides being changed to Immutable; a standardised Date for SQL use; Native JDBC support for DateTime; a function to convert a date from a specified timzeone to some other specified timezone is required. At the moment you can convert from UTC/GMT TO another timezone. This does not help when your date is in something other than UTC/GMT. Sure, the contract for Date is (if i'm correct) a DateTime in UTC/GMT. The current state of affairs with Date is more complex than it needs to be.
#13 - ClassLoaders - Some highly configurable Classloaders are required so that they can be shared across multiple implementations. I would review all major application server venders and the typical needs of simpler J2SE applications. While I do not deny the right for various applications to write their own, I'd rather have projects construct and configure existing classloaders that have been fully tested and are well documented to operate according to their configuration. (same issue as layouts in #7 above).
#14 - Manifest & Command Line - Sort out the frikken commandline. It should be possible to put the memory usage and extension requirements that are typically put across on the commandline into the JAR manifest file. The Runtime should the calculate the union of all requirements required by the various libraries. The libraries should also specify their security requirements. This would allow the runtime to run the application in restricted configuration (usefull for Web Start).
#15 - Release Date - I would like to see a deployment of JDK6 on Windows, Solaris and MacOS X within the same month. This is a major point that is not to be underestimated since Java support on MacOS X is becoming a major drawcard. (I still need to spend money in the Apple department )
#16 - Single JVM - A Single JVM for all Apps? Nice idea but I am not sure I like the lack of isolation in this scenario. Is it possible for 1 GC and 1 RMI host (DGC) for many JVMs. The key point is a mechanism to allow a single 'process' across many JVM instances. This would be alot more difficult than it took for me to seems. Leave this one for the sun engineers to decide. Definately the least of a worry in my eyes. Why do people want a single JVM? Improved performance?
#17 - Web Start Application Server - Some sort of minimalistic application server is required to host java services on any machine that has a runtime _without_ worrying about complex deployment, configuration and management of said application server. One could argue that WebStart has the potential to be perceived as an app server. All thats needed is for the J2SE runtime to support Service Applications (ie:services, windows services, etc). While I dont advocate this as a replacement for an enterprise application server, think it's a good idea.
#17.1 - System Tray and Microsoft Management Console - It would also be nice to be able to expose those 'services' as System Tray applications. Provide A simple framework for services components to integrate themselves into Microsoft Managment Console (platform independant integration into the OS's configuration mechanism) and something similar on Linux and Solaris. I would also embed the 'Java Plugin' into the MMC.
#17.2 - J2EE - I would definately ensure that the 'application server' aspect of proposed Web Start enhancements can be replaced by a fully fledged J2EE application server. Having two on an operating system cannot be good to duplicate this mechanism.
#18 - Web Start Installer - I would like to see Web Start install local applications into its 'cache' before executing them. This could be very similar to how Java Webstart loads remote applications into its application cache. There is _SUCH_ an amazing possibility for this, especially if it could act as some sort of Install Anywhere component. Although I _hate_ to see commercial vendors displaced by SUN solutions, I think its an amazing possibility that benifits all. Possibly providing the install mechanism and having tools like Install Anywhere provide more complex deployment scenarios (eg: Install into Program Files along with Data instead of installing _just_ the JARs, etc). Packaging a native installation bundle is not always _nice_. Java Webstart is currently a single standard mechanism for installing an application. Now improve it. locally.
#19 - Java Operating System - Imagine a Linux whose desktop that only allows Java applications to be executed. It is strung together by some minimalistic windowing manager. Maybe it allows both java applications and native applications to be executed but there is an option to disable the later. Things are 'installed' as per Java Webstart and mentioned webstart enhancements. This is not necessarily for JDK6, but just a thought. A Java Operating System layer.
#19.1 - Security - Some sort of J2SE Domain Controller component should be installed on (for example) a Microsoft Windows Domain Controller or the equivilant for related networks. What I want is better distribution and usage of certificates across a corporation by applications without each application needing to be configured with certificates in its unique way using keys and the commandline. Currently it could be easier.
#19.2 - Trusted Computing - While I dont think its reasonable to have 'Trusted Computing' for native applications (too complex an environment), I do think it should be possible to enforce this in a Java environemnt. With an Java Operating System and a Java Domain Controller it should be pretty straight forward. It could be preinstalled on linux and windows machines that are intended for corperations that require control due to the sensitive nature of the business.
#20 - JVM Object Pooling - JVM support for poolable objects on construction via 'new'. If the object is annotated as poolable, and its a candidate for collection, then it should be moved into a pool for reuse on construction. I'm not sure how performance would be effected. With the advances of the JVM, this should not be a major issue, but the question must be asked: Is it possible for any substantial improvement to be gained from lightweight objects? If not, then dont bother. I see pooling very usefull for those heavy weight components (JDBC connection required) but I would hesitate to delegate pooling to the JVM in such a case.
#21 - Documentation - While opensource projects such as Hibernate have complex documentation requirements, so do internal applications. The standardisation of JavaDocs brought about sites such as jdocs.com and a general improvement in the level of documentation. I can only stress the need again to provide a standard, such as javadocs, for the entire project so that larger sets of information can be organised and consolidated project by project. While many might say that the web links everything, I would still say that the MSDN is alot more organised than just about any other technology site. The key is organisation and while I dont want to indicate that open source projects should standardise, I am refering to my internal projet documentation requirements for my applications on my intranet. The same technologies are typically visible in systems like jdocs.com where organisation can bring about some advantage. Every project has similar set of documentation requirements. Why not standardise what can be standardised and provide a simple mechanism to include unstructured and nonstandard documentation layouts. If anything, there is the advantage that more projects will provide a more complete set of documentation. Again, while some can relate to the use of open source projects, I highlight the need for documentation within the intranet.
Message was edited by: tim12s