Skip to main content

Best Threads and Ideas - Summary (by Topic)

34 replies [Last post]
tim12s
Offline
Joined: 2004-02-02
Points: 0

Updated to arrange best ideas listed in threads according to topic.
----------------

I'm going to find RFEs and relate them to the topics below or I will submit RFEs for topics that are not covered. Anyone want to double check and expand on any additional items below?

Topics
------
The 'actionable items' of thread and idea were listed and sorted according to topic. Duplicates and justifications were removed. Topics are listed below before [Thread Index].

Threads
-------

This contains a list of some of the best ideas mentioned and discussed (in my opinion) and are listed and summarised below. The index is in order of 'last modified' at the time of list composition.

Summaries cover what is wanted and excludes justifications. I will remove justifications from the last 'block' when I have time.

Alot of the statements are _directly quoted_ from posters in mentioned threads and possibly changed slightly to improve readability without changing meaning.

Topic Index
-----------
Desktop Integration Components + Web Start + JNLP
WebStart + Security
WebStart
MANIFEST.MF
Swing
Sun
JNI
Breaking Changes
Minor
Image Acquisition JSR
File & Network I/O
Language
Java Beans
General
Generics
JVM
Windows
XML
Documentation
Documentation Contents
RMI and Remote
Application Stack
Java Operating System Layer
Security
Classloader
Development
Official Abstract Syntax Tree for Java

Desktop Integration Components + Web Start + JNLP
-------------------------------------------------
* Integrate the Java Control Panel into Microsoft Management Console
* Improve or allow for application integration with the Java Control Panel.
* Installation of system tray applications through WebStart.
* Improve tight Windows integration and WORA integration with other platforms.

WebStart + Security
-------------------
* Break down security access into groups and categories that can be easily understood in the

java control panel.
* Allow webstart to enforce well established levels of security on both signed and unsigned applications.
* Add trust levels that shows what level of trust an appliction requires.
* Make the warning when running unsigned JWS applications less hostile as it currently makes the user _really_ want to press NO.

WebStart
--------
* Resume downloads of partially downloaded JWS applications.
* Pre-packaged WAR archive that extracts and installs via JNLP onto the local machine.
* WebStart ought to be extended so that it can be used for server side processes and command line applications. Server side processes require some sort of 'container' that is either native or webstart specific or some J2EE application server.
* More JNLP options on when and how to update remote and offline applications.
* If you can't make a socket connection from within a secure (unsigned) JWS application you are forcing the majority of applications to require enough permissions to be able to install spyware and viruses. Finegrained security trust levels will solve this.
* Include the possibility for an applications MANIFEST file to list remote libraries. The Java Runtime should load these libraries into a java webstart protected container ensuring that version conflicts are not issues between applications.
* Allow webstart to install 'local' applications into its cache before executing them.
* Improve packaging and security issues around native libraries and webstart
* Allow partial JVM deployment (2mb JVM download).
* Allow multiple versions of the same packages to be installed by WebStart.
* Managed sharing of the libaries between installed applications
* Merge java, javaw and javaws into a single executable.
* There must be some way to load a desired version of component from a package instead of depending upon the user specifying X.jar in front of Y.jar in the classpath to ensure that my code runs properly.
* 'Application server' aspect of background server services should allow complete replacement by fully fledged J2EE application servers.
* Add support for library downloads via company authority defined by the JRE or as per the JNLP definition. Include JRE libraries and JWSDP libraries and other critical but shared components (see application stack for for further components).
* Integration of java webstart safe components into standard swing components/controls.

MANIFEST.MF
-----------
* Allow the manifest.mf to contain minimum and maximum required memory per .JAR.
* Allow the manifest.mf to contain extra runtime parameters.
* Allow the manifest.mf to support remote library installation via webstart.
* Force version requirements in of manifest.mf
* Ask for a max-heap of say 30% of the max memory the client has installed or a minimum of 128mb -- whichever is larger.
* Specify required java package versions.
* JVM should support the package management and dependency tracking by default.
* Package/jar/module dependecies and requirements should be more precisely specifiable and application/runtime should be able to verify these requirements.

Swing
-----
* Swing: Windows look-and-feel so Swing apps look native.
* Swing: Add support for ClearType.
* Swing: Allow things to get repainted while the window is being resized.
* Swing's HTML parsing and rendering classes suffer under a monolithic release cycle because HTML develops faster than Java.
* turn off the titlebar for your application and have Swing draw one improves skinnability of application.
* task-tray integration.
* "always on top" windows.
* transparent windows.
* setMinimumSize in AWT Frames to work consistently on all platforms.
* review http://uic.sf.net
* Analyse 3rd party tools and introduce the best custom layouts into the jdk
* A decent Java based browser/html viewer for Swing would be very handy.
* JComponent should have a certain min/max/preferred width but no min/max/preferred height or m/m/p height but no m/m/p width. (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4903046)
* Make the Actions framwork so it can handle checkbox items as well (in menus).
* Common buttonmodel so they all change when one changes, with only one event fired.
* More values to customize the components created with an Action - initial state of the checkbox, multiple icon sizes.
* Swing: Add translucent top-level windows.
* Swing: Non-rectanglular windows with hit-area for mouse events.
* Swing: Accelerate everything in Java2D and produce a document that specifies what is accelerated when and on which platforms.
* Swing: Road map for when things will be accelerated.
* Swing: Fix Windows L&F to the spec of Winlaf and JGoodies windows XP.
* Swing: Add/fix really good font support.
* Swing: Use an Integer in the properties to set a cut-boundary over which font-size to AA automatically in a GUI. A value of null would indicate platforma preference and no value at all would (maybe) make all be as today.
* Swing: Add a type of Stroke that draws the inside of a shape and not always a bottom/right offset as BasicStroke does.
* Swing: Add a good (not good enough) docking layout manager (not a docking framwork!).
* Provide an action framework to minimise issues with the threading model.
* A simple way to manage actions and workers.
* Management of actions, long running actions, actions on popups sensitive to JTree, etc.
* Management of actions relating to plugins, etc.
* Consider Swixml swing frameworks.
* Application Stack is required so we can have J2SE components not bundled with the J2SE allowing them to advance quicker than the release schedule of J2SE.
* Look at and review "Foxtrot".
* Review 3rd party layouts or solicit recommendations and add more layouts reducing the need for 3rd party tools (netbeans, intellij, etc) to introduce their own layouts.
* Improve the event action mechanism by providing an action framework that makes it easier to correctly develop a large swing application. Surely common plumbing issues like toolbars, menuitems, popups and long running actions/activities can be generalised into some framework.
* Introduce support for plugins and modules in this application framework.
* Additional datamodel implementations that make it easier to work with databound or entity bound information along with a master-detail model/mechanism or abstraction and generalisation of the required mechanism.
* Swing: Review 3rd party tools (such as SwixML) and understand their Swing issues.

Sun
---
* A better user interface is needed for bug parade.
* java.net may be a better place to plan and develop some JCP components.
* Allow people to vote for/against proposed changes.
* Fix the *social* problem: better communication between Sun engineers and end-users.
* Ability of end-users to include screenshots and other useful attachments when filing issues on BugParade.
* SUN could negotiate a very nice contract (JIRA) which would benefit both organizations to improve bug tracker.
* For certain projects (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.
* Use java.net effectively as a Java Technology Developers Network that will centralize and host any effective articles from individuals, from 3rd party sites such as JavaWorld without removing credits or advertisements from said self sponsored sites.
* Use java.net to effectively preserve sites such as javapractices.com, javaalmanac.com, ootips.org, articles, HOWTOs, benchmarks, etc.
* Increase presence on newsgroups and support forums.
* Ensure that self sponsored communities have a mechanism to put across their exposure. Possibly more detrimental than effectively indexing those few sites that are effective at providing support articles.
* Quality information and articles must not be hidden, the JTDN (Java Technology Developers Network) should maximise the exposure to this information and all articles should be peer reviewed and published once a year on CD.

JNI
---
* JVM provide automatic marshalling from and to C types.
* Make JNI as easy as @Library("mylib.so") public native myCMethod();
* JACE http://sourceforge.net/projects/jace

Breaking Changes
----------------
* Replace Java's date/time classes with Joda or something better and immutable.
* Identify immutable candidates and make them immutable (Point, dimension, etc)
* Decide on how to identify an immutable class and when a class should be immutable.
* Introduce Breaking changes by removing and refactoring deprecated methods, classes and functions.
* Have java documentation not include documentation about deprecated functions.
* Replace uses of Enumeration, Vector, etc, in Swing APIs.
* Methods such as getExpandedDescendants() and getDescendantToggledPaths() in JTree return Enumerations rather than Iterators.
* JList constructor can take a Vector but not any other type of collection.
* JList should take a Collection and iterate over that to get the list elements.
* The holy cow of compatibility needs to be butchered. J3SE? (massive removal of deprecated features).
* http://uic.sourceforge.net/api/20/uic/widgets/UICList.html
* Fix, wrap or redo Calendar/Date.
* Ensure that major breaking changes are all performed at once. Preferrably solve all breaking changes for the next 10 years.
* Date: Standardise date for SQL use amongst DateTime, Date and Time, etc.
* Date: A date function to convert one DateTime in a specified timezone to some other timezone. (Current functions assume Date is in UTC and convert from UTC to some other timezone).
* Remove duplicate issues (Old Way vs New Way) where there is significant legacy.

Minor
-----
* a static method boolan Integer.isInteger(String) that returns true in the same cases when the parseInt(String) method is successful
* java.util.Collections.EMPTY_SET and results of java.util.Collections.singleton(Object o) should implement the java.util.SortedSet interface
* Ability to iterate a BitSet.
* Review jakarta toolkits and determine what utility functions should be closer to the JDK for developers who do not use similar toolkits.

Image Acquisition JSR
---------------------
* an image acquisition api that must not belong in the base JDK
* a few default implementations like twain wrapper on windows & mac
* a pluggable architecture so that third party providers and systems can write adaptors for their devices

File & Network I/O
------------------
* listens to the file system change notifications and raises events when a directories or files change.
* Add IO static methods to close streams quietly.
* Review all Apache Jakarta Commons Lang, IO and Collections as some of them should be in the JDK.
* NIO: Continue NIO support for selector on file, multicast channel, etc.
* Advanced & Raw Socket Support (ICMP, ICMPv6, ping, traceroute, ...)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4727550

Language
--------
* When a switch involves objects, macro expand this to a complex if/elseif .equals
* Have synchronize use an developer defined lock object instead of itself iff the object overrides some mechanism to provide the lock object.
* Add a Delegate class (Object+Method).
* Add a Property class (Object+Field).
* Create a read only array to help against defensive copying.
* Use the 'class' keyword in methods similar to 'this' by not requiring the Class Name prefix. (Foo.class).
* About C++ const and how it'd be nice to have more immutable objects by design.
* May require return narrow return type. eg: MyObject clone() narrows Object clone().
* Default constructor for ClassCastException should be deprecated and removed because it is useless: it does not provide information to resolve error. (public ClassCastException(Class expected, Class offending))
* unsigned int and unsigned byte either JVM or compiler support for automatic byte b=0xff&i;

Java Beans
----------
* Properties instead of the get/set convention.
* update the java beans spec to deal with reality like collections.
* Properties and collections should be recognized with Collection<> getValues() and void setValues(Collection<> values) instead of Object[]getValues() and void setValues(Object[]).
* Fix the JavaBean spec to uses List and Map objects.

General
-------
* Make compile clean using @SuppressWarnings.
* Clean JavaDocs.
* Remove dead code/variables.
* Remove unnecessary use of reflection and inappropriate dependencies.
* Remove REMINDs (together with reasons why they are there).
* Remove kludges.
* Remove bugs relating to creation of Swing objects outside of the EDT.
* Use FindBugs and/or equivalents to remove inappropriately synchronised code and other common errors.
* Tidy up the demos.
* Remove BCEL.
* There are plenty of small easily fixed bugs in the Bug Parade.
* Have a major look at all the old features and fill in the 5% that is missing from many of them.
* Remove dependancy on the need for developers to use com.sun classes in the JDK and define interfaces for those areas that need further specification.
* All resources that need to be freed use a consistent API (dispose(), close(), etc...). Pick one or at least ensure that it is explicit in JavaDocs. Have classes implement interfaces for Disposable or closable.

Generics
--------
* List l = new ArrayList() should throw a ClassCastException on l.add(new Double(1.1));
* Runtime support enabled via for -enableruntimegenerics (similar to assertions)
* T[] t = new T[size]; (generic arrays)
* Add addAll(<? extends E>[] array) to collections making them more array compatible.
* Add containsAll(<? extends E>[] array) to collections making them more array compatible.
* Add removeAll(<? extends E>[] array) to collections making them more array compatible.
* Add retainAll(<? extends E>[] array) to collections making them more array compatible.
* Add E[] toArray() (this requires type erasure and return type overloading of Object[] toArray()).
* Prevent the need for addAll(Arrays.asList(array)).

JVM
---
* Release memory pages back to OS by default when free memory crosses a threshold.
* Limit the amount of memory usable by JVM compartments.
* Improve security to be enforced per 'compartment'.
* JSR 121: Application Isolation API.
* Auto Updating JRE from SUN or from intranet server / etc.
* Personal firewalls treat all Java applications as the same program instead of seperate programs because of java.exe being the executable.

Windows
-------
* A Windows mechanism to distinguish executable jars from normal jars. (.JAR and .JRE or .JRX)
* Many users seem to have jar associated with winzip, powerarchiver, etc this should not be the case for executable jars.
* Improve COM+ component integration.

XML
---
* http://www.csse.monash.edu.au/~bren/JSX.
* Serialize any class very easily to XML.
* While XMLEncoder is AFAIK just JavaBean serializer, JSX is object serialization solution.
* An XML pull parser could be integrated to JAXP (like C# pull parser) see http://www.xmlpull.org/

Documentation
-------------
* Advance javadoc standard doclet to support more artifacts that are not related to an API but are usefull to embed inside source code. (like psv main execution parameters, configuration settings, etc).
* Some sort of common bundling mechanism or layout standard should be agreed upon for merging documentation, articles, HOWTO, FAQ, etc.
* Provide doclets and mechanisms for merging documentation offline and online.
* Improve total project documentation by looking at javadocs and understand what can be added to improve all projects documentation requirements.
* Generalise complex project documentation providing mechanisms other than API generation.
* Provide documentation standards for projects and different types of projects understanding how documentation inside a company is organised and how the documentation outputs of different projects must be organised and must integrate.
* MSDN is alot more organised than just about any project or company website, why?
* Review http://ndoclet.sourceforge.net and maybe get the bloke who is doing that to incorporate and submit enhancements to the standard doclet.
* standard doclet should be extended to allow package comments, method comments and in-source comments to generate 'articles'. These articles should allow related topics to be detailed where they are appropriate and are then stiched together during javadocs and could cover topics like configuration parameters, executable parameters, to be included in some sort of TOPIC index that is generated along with the API docs.
* HTML browsers are not a good host for huge, complex docsets. Please move to a JavaHelp-based viewer so we also get decent index and search and other features that can be programmed easily with JavaHelp.

Documentation Contents
----------------------
* Ensure that it is possible for all J2EE, J2SE and J2ME docs to be online in a single online documentation archive along with other ALL other sun and JSR api documentations, etc. (All indexed)
* More pictures - Graphics object does rotations around an coordinate system that is not intuitive.
* Lack of integration between documentation sets from multiple APIs.
* A single monolithic doctset with ALL the APIs and update it whenever ANY single API is updated.
* A single monolithic tutorial and make them more integrated with the javadocs.
* Cross-reference stuff to jump from tutorial, demo, or guide that explains or uses this particular API. (Huge work, must be automated with source articles specifying their relation to online documentation)
* Documentation which tells you about settings and properties without going into specific details must be made more specific about allowable values and expected values and defaults and recommended alternatives.
* There could be more links to tutorials for complicated topics. There are tons of links for Swing, but e.g. no link from any java.lang.reflect classes to the reflection tutorial.
* Package documentation should include more architectural and design documentation on how it is expected that certain interfaces should be used.
* Include code examples in the documentation for each method or class.
* Tag methods and classes and objects as being major classes or primary classes and relating them to 'Obtain', 'Modify' and 'Use', allowing the utility and helper classes to be easily ignored by developers and extra highlighting of class indexes.
* "How would I normally get one of these" ("Obtain")
* "How would I normally configure it to my n
* "What is the common ways to use this class once I have one" (Use)
* Create a search 'applet' that allows javadocs to be offline searchable.
* Editable online documentation for quicker improvement in incorrect documentation.

RMI and Remote
--------------
* Review ALT RMI and other RMI implementations.
* Seperate channel functionality (HTTP, TCP, etc) into better controllable subsystem.
* Support objects exposed over multiple IP ports and channels. (Currently exposed over a single IP port).
* @remote as an annotation to specify access to the method as a web service

Application Stack
-----------------
* Buy or cross license a set of commercial applications that provide complete coverage of development needs. (Think MSDN license)
* Tools like JAR to EXE converter, Install Anywhere, IntelliJ IDEA, Atlassian JIRA, JGoodies, database swing controls, etc, should all be included in said Java Developer Network License. Components not necessarily developed by SUN should be included in this developer license sold per seat. (My company buys 1 MSDN license per developer with no known such license in the Java world).
* SwixML / XML Layout mechanism included in an application stack (discussed later)
* Java Help to be included in an application stack (discussed later)
* Critiqued by the community and versions feature frozen with bugfixes and updated regularly to include additional features.

Java Operating System Layer
---------------------------
* A JRE must be a configurable slave of a company domain such that certificate issues and application deployment may be trusted.
* Trusted computing and issues of trusted computing should be possible if the JOSL (Java Operating System Layer) takes control of the desktop and operating system allowing only (?) JNLP or other Java Webstart applications to execute. (On linux this makes sense. By possibly ensuring at the kernel level that only java applications may be executed, it may make an intresting security proposition and company deployment.)
* Java Domain Controller gets installed on company servers to manage JRE secure runtimes on different computers.
* JOSL preinstalled on linux computers allowing some sort of 'Java' only trusted desktop.
* Better management of security keystores by users through the Java Control Panel.

Security
--------
* A means to distinguish between trusted Java apps and some ropey spyware Applet.
* Allow a JAR to specify the rights that it needs so that through analysis one can understand which components need what types of security allowing the runtime to enforce said security policy on a per-jar-per-package basis and allowing users to understand the security profile of an application. This could be extended in a company environment where a company trusts certain identified libraries across the company and all libraries signed by the company as being 'safe' for expected access permissions.

Classloader
-----------
* Understand 3rd party Classloader neads and introduce a couple of highly configurable classloaders application developers needs dont have to write them.

Development
-----------
* JDK must include a graphical installation packaging tool that can review a packaged application and manage all MANIFEST.MF settings and other issues like package and jar signing aswell as the generation of a script that will perform the same settings on similar JAR files. Applies to applets, JNLP standard applications, and applications other than standard J2EE applications.

Official Abstract Syntax Tree for Java
--------------------------------------
* J2SE should specify a standard abstract syntax tree implementation for Java.
* This form should be annotable for flexible extension.
* May overlap with JSR 198
* Rewrite apt so that it exposes a writable version of this standard AST.
* Allow the development of code that reasons about other Java code without having to depend on a particular Java parser's specific AST implementation.

Thread Index
------------

Nominated project: Joda Time
http://forums.java.net/jive/thread.jspa?threadID=198

static boolan Integer.isInteger(String)
http://forums.java.net/jive/thread.jspa?threadID=196

Add support for .NET
http://forums.java.net/jive/thread.jspa?threadID=186

Const or Immutable objects
http://forums.java.net/jive/thread.jspa?threadID=59

Operator overloading (again) and functions
http://forums.java.net/jive/thread.jspa?threadID=192

Resume support in WebStart
http://forums.java.net/jive/thread.jspa?threadID=185

EMPTY_SET and SingletonSet should implement SortedSet
http://forums.java.net/jive/thread.jspa?threadID=179

Iterating a BitSet
http://forums.java.net/jive/thread.jspa?threadID=178

image acquisition API
http://forums.java.net/jive/thread.jspa?threadID=172

FileSystemWatcher
http://forums.java.net/jive/thread.jspa?threadID=171

Makes switch() and case: work with any object or primitive
http://forums.java.net/jive/thread.jspa?threadID=153

Make Collection and arrays more compatible
http://forums.java.net/jive/thread.jspa?threadID=163

No broken windows
http://forums.java.net/jive/thread.jspa?threadID=160

Re: If you could get rid of one thing from Java...
http://forums.java.net/jive/thread.jspa?threadID=106

Welcome
http://forums.java.net/jive/thread.jspa?threadID=44

@remote added to annotations
http://forums.java.net/jive/thread.jspa?threadID=155

Ubiquitous JRE deployment... partner with Mozilla/Firefox?
http://forums.java.net/jive/thread.jspa?threadID=71

Synth Look & Feel supports Window Decoration
http://forums.java.net/jive/thread.jspa?threadID=149

Make 'class' keyword work the same way as 'this'
http://forums.java.net/jive/thread.jspa?threadID=152

Runtime Type Safety and Inheritance for Generics
http://forums.java.net/jive/thread.jspa?threadID=92

Language,Bugs,Documentation,Webstart,Application Stack, + Lots
http://forums.java.net/jive/thread.jspa?threadID=125

Dynamic Upper Memory Limit for the JVM
http://forums.java.net/jive/thread.jspa?threadID=139

Re: Const or Immutable objects
http://forums.java.net/jive/thread.jspa?threadID=59

AWT/Swing improvements
http://forums.java.net/jive/thread.jspa?threadID=46

Enhance/fix GridBagLayout somewhat
http://forums.java.net/jive/thread.jspa?threadID=124

Integration of javaws and java/javaw
http://forums.java.net/jive/thread.jspa?threadID=136

Make JNI simpler to use
http://forums.java.net/jive/thread.jspa?threadID=112

Official Abstract Syntax Tree (AST) for Java
http://forums.java.net/jive/thread.jspa?threadID=61

Documentation enhancements
http://forums.java.net/jive/thread.jspa?threadID=62

A few ideas off the top of my head
http://forums.java.net/jive/thread.jspa?threadID=57

Replace uses of Enumeration, Vector, etc, in Swing APIs
http://forums.java.net/jive/thread.jspa?threadID=117

Improve Beans with collection
http://forums.java.net/jive/thread.jspa?threadID=105

Swing threading model
http://forums.java.net/jive/thread.jspa?threadID=67

More flexible min/max/preferred width and height for components
http://forums.java.net/jive/thread.jspa?threadID=60

Replace XMLEncoder, Serializable by JSX?
http://forums.java.net/jive/thread.jspa?threadID=97

ClassCastException should always report incompatible type
http://forums.java.net/jive/thread.jspa?threadID=98

Solve Jar Hell (JDK10?)
http://forums.java.net/jive/thread.jspa?threadID=83

Polish, consolidate and fix bugs.
http://forums.java.net/jive/thread.jspa?threadID=48

Associative class searching
http://forums.java.net/jive/thread.jspa?threadID=85

New technologies
http://forums.java.net/jive/thread.jspa?threadID=63

RFEs vs. Bugs
http://forums.java.net/jive/thread.jspa?threadID=64

Administration of Libaries
http://forums.java.net/jive/thread.jspa?threadID=75

JWS: Installation Package
http://forums.java.net/jive/thread.jspa?threadID=70

JWS SocketService RFE 4876235
http://forums.java.net/jive/thread.jspa?threadID=55

Thread Details
--------------

Nominated project: Joda Time
http://forums.java.net/jive/thread.jspa?threadID=198

* Replace Java's date/time classes with Joda
* integration issues (JDBC) must be solved
* UTC relative to some base date and basic string conversions to/from ISO8601 form
* table of the leap seconds that have been declared to date and a mechanism to update this

--------

static boolan Integer.isInteger(String)
http://forums.java.net/jive/thread.jspa?threadID=196

* a method static boolan Integer.isInteger(String) that returns true in the same cases when the parseInt(String) method is successful

--------

Add support for .NET
http://forums.java.net/jive/thread.jspa?threadID=186

* RFE: javax.desktop package
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4915908
* RFE: Access to desktop notification area, i.e. Windows Systray
* http://developer.java.sun.com/developer/bugParade/bugs/4737770.html
* RFE: Windows taskbar notification/flashing support
* http://developer.java.sun.com/developer/bugParade/bugs/4902807.html
* Add a system method for launching the user's default browser
* http://developer.java.sun.com/developer/bugParade/bugs/4210168.html
* Programmatic access to network parameters
* http://developer.java.sun.com/developer/bugParade/bugs/4691932.html

* Integration of the Java Activation Framework and its native counterpart.

--------

Const or Immutable objects
http://forums.java.net/jive/thread.jspa?threadID=59

* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4211070

--------

Operator overloading (again) and functions
http://forums.java.net/jive/thread.jspa?threadID=192

* operator overloading only usable within the java.* and javax.* package hierarchies
* allow JCP JSRs to add well thought out operators while not allowing the abuse

--------

Resume support in WebStart
http://forums.java.net/jive/thread.jspa?threadID=185

* supported resuming downloads

--------

EMPTY_SET and SingletonSet should implement SortedSet
http://forums.java.net/jive/thread.jspa?threadID=179

* java.util.Collections.EMPTY_SET and results of java.util.Collections.singleton(Object o) should implement the java.util.SortedSet interface

--------

Iterating a BitSet
http://forums.java.net/jive/thread.jspa?threadID=178

* Iterate a BitSet

--------

image acquisition API
http://forums.java.net/jive/thread.jspa?threadID=172

* an image acquisition api
* a few default implementations like twain wrapper on windows & mac
* a pluggable architecture so that third party providers and systems can write adaptors for their devices
* APIs must not belong in the base JDK
* image acquisition JSR

--------

FileSystemWatcher
http://forums.java.net/jive/thread.jspa?threadID=171

* listens to the file system change notifications and raises events when a directories or files change.

--------

Makes switch() and case: work with any object or primitive
http://forums.java.net/jive/thread.jspa?threadID=153

* When a switch involves objects, macro expand this to a complex if/elseif .equals

--------

Make Collection and arrays more compatible
http://forums.java.net/jive/thread.jspa?threadID=163

* Add addAll(<? extends E>[] array).
* Add containsAll(<? extends E>[] array).
* Add removeAll(<? extends E>[] array).
* Add retainAll(<? extends E>[] array).
* Maybe create another interface so that existing code won't be broken.
* Add E[] toArray() (this requires type erasure and return type overloading of Object[] toArray()).
* Prevent the need for addAll(Arrays.asList(array)).

--------

No broken windows
http://forums.java.net/jive/thread.jspa?threadID=160

* Make compile clean using @SuppressWarnings.
* Clean JavaDocs.
* Remove dead code/variables.
* Remove unnecessary use of reflection and inappropriate dependencies.
* Remove REMINDs (together with reasons why they are there).
* Remove kludges.
* Remove bugs relating to creation of Swing objects outside of the EDT.
* Use FindBugs and/or equivalents to remove inappropriately synchronised code and other common errors.
* Tidy up the demos.
* Remove BCEL.
* There are plenty of small easily fixed bugs in the Bug Parade.

--------

Re: If you could get rid of one thing from Java...
http://forums.java.net/jive/thread.jspa?threadID=106

* Have synchronize use an objects LOCK OBJECT instead of itself IFF the object overrides some mechanism to provide the lock object.

--------

Welcome
http://forums.java.net/jive/thread.jspa?threadID=44

* Swing: Windows look-and-feel so Swing apps look native.
* Swing: Add support for ClearType.
* Swing: Allow things to get repainted while the window is being resized.
* Limit the amount of memory usable by JVM compartments.
* Improve security to be enforced per 'compartment'.
* Properties instead of the get/set convention.
* A better user interface is needed for bug parade.
* java.net may be a better place to plan and develop some JCP components.
* Swing's HTML parsing and rendering classes suffer under a monolithic release cycle because HTML develops faster than Java.
* Allow people to vote for/against proposed changes.
* update the java beans spec to deal with reality like collections.
* replace Calendar/Date - consider http://joda-time.sourceforge.net.
* Add a Delegate class (Object+Method).
* Add a Property class (Object+Field).
* Add IO static methods to close streams quietly.
* In fact review all Apache Jakarta Commons Lang, IO and Collections as some of them should be in the JDK.
* Spend at least 50% of the whole coding effort of 1.6 on tidying up/minor teaks to/polishing what you already have.
* Create a read only array to help against defensive copying.
* NIO: Continue NIO support for selector on file, multicast channel, etc.
* JSR 121: Application Isolation API.
* Allow partial deployment (2mb JVM download).
* MUCH finer grained security permissions in WebStart.

--------

@remote added to annotations
http://forums.java.net/jive/thread.jspa?threadID=155

* @remote as an annotation to specify access to the method as a web service.

--------

Ubiquitous JRE deployment... partner with Mozilla/Firefox?
http://forums.java.net/jive/thread.jspa?threadID=71

* Auto Updating JRE from SUN or from intranet server / etc.

--------

Synth Look & Feel supports Window Decoration
http://forums.java.net/jive/thread.jspa?threadID=149

* turn off the titlebar for your application and have Swing draw one improves skinnability of application.

--------

Make 'class' keyword work the same way as 'this'
http://forums.java.net/jive/thread.jspa?threadID=152

* Use the 'class' keyword in methods similar to 'this' by not requiring the Class Name prefix. (Foo.class).

--------

Runtime Type Safety and Inheritance for Generics
http://forums.java.net/jive/thread.jspa?threadID=92

* List l = new ArrayList() should throw a ClassCastException on l.add(new Double(1.1));
* Runtime support for -enableruntimegenerics (similar to assertions)

--------

Language,Bugs,Documentation,Webstart,Application Stack, + Lots
http://forums.java.net/jive/thread.jspa?threadID=125

* These comments have been moved to the bottom of this document as there are too many of them to be reasonably listed here.

--------

Dynamic Upper Memory Limit for the JVM
http://forums.java.net/jive/thread.jspa?threadID=139

* Release memory pages back to OS by default when free memory crosses a threshold.

--------

Re: Const or Immutable objects
http://forums.java.net/jive/thread.jspa?threadID=59

* About C++ const and how it'd be nice to have more immutable objects by design.

--------

AWT/Swing improvements
http://forums.java.net/jive/thread.jspa?threadID=46

* task-tray integration.
* "always on top" windows.
* transparent windows.
* setMinimumSize in AWT Frames to work consistently on all platforms.
* review http://uic.sf.net

--------

Enhance/fix GridBagLayout somewhat
http://forums.java.net/jive/thread.jspa?threadID=124

* Fix Grid Bag Layout, it has problems.
* Dont fix GBL, fixing it would introduce compatability issues.
* Add a Docking Layout
o Solve 'issues' by analysing 3rd party tools and introducing the custom layouts to the JDK.
o Ensure that custom layouts are suffucient to solve 3rd party neads.

--------

Integration of javaws and java/javaw
http://forums.java.net/jive/thread.jspa?threadID=136

* Merge java, javaw and javaws into a single executable.
* Allow the MANIFEST.MF to contain execute properties.
* Improve application integration with the Java Control Panel.
* Allow JNLP secure and unsecure objects so that a Java WS app can be used outside Java WS.

--------

Make JNI simpler to use
http://forums.java.net/jive/thread.jspa?threadID=112

* JVM provide automatic marshalling from and to C types.
* Make JNI as easy as @Library("mylib.so") public native myCMethod();
* JACE http://sourceforge.net/projects/jace

--------

Official Abstract Syntax Tree (AST) for Java
http://forums.java.net/jive/thread.jspa?threadID=61

* J2SE should specify a standard abstract syntax tree implementation for Java.
* This form should be annotable for flexible extension.
* AST should be easily serializable to and from XML.
* May overlap with JSR 198
* Rewrite apt so that it exposes a writable version of this standard AST.
* Write code that reasons about other Java code without having to depend on a particular Java parser's specific AST implementation.

J An official AST for Java could drive the cost of a lot of valuable development tools down.
J Tools like refactoring engines, semantic search, static analyzers, metrics, layout, duplicate finders, test coverage analyzers, test case generators, and program structure and execution visualizers.

--------

Documentation enhancements
http://forums.java.net/jive/thread.jspa?threadID=62

* More pictures - Graphics object does rotations around an coordinate system that is not intuitive.
* major problem in javadocs is the lack of integration btw documentation sets from multiple APIs.
* Index pages with every API from J2SE, J2EE, J2ME, and also *all* other Sun APIs that are not included in any of these J2*E platforms
* a single monolithic doctset with ALL the APIs and update it whenever ANY single API is updated.
* a single monolithic tutorial and make them more integrated with the javadocs.
* Cross-reference stuff to jump from tutorial, demo, or guide that explains or uses this particular API. (Huge work, must be automated)
* HTML browsers are not a good host for huge, complex docsets. Please move to a JavaHelp-based viewer so we also get decent index and search and other features that can be programmed easily with JavaHelp.
* documentation which tells you about settings and properties without going into specific details must be made more specific.
* standard doclet should be extended to allow package comments, method comments and in-source comments to generate 'articles'. These articles should allow related topics to be detailed where they are appropriate and are then stiched together during javadocs and could cover configuration parameters, executable parameters, etc to be configured.
* Some sort of 'Article' standard is required allowing documentation other than API to be bundled and integrated.
* Java Technology Developer Network - something similar to jdocs.com but for user manuals, articles, HOWTOs, bug reports, etc.
* Create a search 'applet' that allows javadocs to be offline searchable.
* Editable online documentation for quicker improvement in incorrect documentation.
* Make the JDK 1.5.1 documentation available while it is being developed.
* There could be more links to tutorials for complicated topics. There are tons of links for Swing, but e.g. no link from any java.lang.reflect classes to the reflection tutorial.
* All API JavaDocs should be available for browsing online. (2ME API JavaDocs are currently only available for download as a zipfile).
* Support a new JavaDoc toolkit based on something like Ashkelon http://ashkelon.sourceforge.net
* Ashkelon could be extended with a REST/SOAP download mechanism so that new APIs could be downloaded easily as needed.
* More examples in the javadocs. A pointer to the java tutorial pages would be better than nothing. Many of the MS docs have little code examples.
* ALL resources that need to be freed use a consistent API (dispose(), close(), etc...). Pick one or at least ensure that it is explicit in JavaDocs.
* Tag methods and classes and objects as being major classes or Core classes and relating them to 'Obtain', 'Modify' and 'Use', allowing the utility and helper classes to be easily ignored by developers.
* "How would I normally get one of these" ("Obtain")
* "How would I normally configure it to my needs" (Modify)
* "What is the common ways to use this class once I have one" (Use)

--------

A few ideas off the top of my head
http://forums.java.net/jive/thread.jspa?threadID=57

* getSize() method on Collection.
* Controlled the startup of JVM through JNLP or MANIFEST.MF
* Reengineer of the classloader mechanism to support Isolates, shared spaces and shared JVM.
* A Windows mechanism to distinguish executable jars from normal jars. (.JAR and .JRE or .JRX)
* SAR (Standalone Application aRchive) or JRE (Java Archive Executable).
* Improved MANIFEST.MF to support extended configuration.
* Many users seem to have jar associated with winzip, powerarchiver, etc.
* A decent Java based browser/html viewer for Swing would be very handy.
* Ask for a max-heap of say 30% of the max memory the client has installed or a minimum of 128mb -- whichever is larger.
* Can the executable jars also have some of these extra runtime parameters in the manifest.
* Reduce the task priority assigned to my Java apps under Windows. (Platform independant)
* A means to control/throttle thread usage. (Platform independant)
* Personal firewalls treat all Java applications as the same program instead of seperate programs.
* A means to distinguish between trusted Java apps and some ropey spyware Applet.
* Allow MANIFEST.MF to specify an internal application classloader that will load files accordingly.
* Improve MANIFEST.MF classloader to support remote library installation. (Web Start ?)

--------

Replace uses of Enumeration, Vector, etc, in Swing APIs
http://forums.java.net/jive/thread.jspa?threadID=117

* Introduce Breaking changes by removing and refactoring deprecated issues.
* Replace uses of Enumeration, Vector, etc, in Swing APIs.
* Methods such as getExpandedDescendants() and getDescendantToggledPaths() in JTree return Enumerations rather than Iterators.
* JList constructor can take a Vector but not any other type of collection.
* JList should take a Collection and iterate over that to get the list elements.
* The wholy cow of compatibility needs to be butchered. J3SE? (massive removal of deprecated features).
* http://uic.sourceforge.net/api/20/uic/widgets/UICList.html

--------

Improve Beans with collection
http://forums.java.net/jive/thread.jspa?threadID=105

* Properties should be recognized with Collection<> getValues() and void setValues(Collection<> values) instead of Object[]getValues() and void setValues(Object[]).
* Fix the ancient JavaBean spec to modern realities, everyone uses List and Map objects in their beans these days.
* May require return narrow return type. eg: MyObject clone() narrows Object clone().

--------

Swing threading model
http://forums.java.net/jive/thread.jspa?threadID=67

* Sort out the Swing Threading Model.
* Provide an action framework to minimise issues with the threading model.
* Look at and review "Foxtrot".
* A simple way to manage actions and workers.
* Management of actions, long running actions, actions on popups sensitive to JTree, etc.
* Management of actions relating to plugins, etc.
* Consider Swixml swing frameworks.
* Application Stack is required so we can have J2SE components not bundled with the J2SE allowing them to advance quicker than the release schedule of J2SE.

--------

More flexible min/max/preferred width and height for components
http://forums.java.net/jive/thread.jspa?threadID=60

* JComponent should have a certain min/max/preferred width but no min/max/preferred height or m/m/p height but no m/m/p width.
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4903046

--------

Replace XMLEncoder, Serializable by JSX?
http://forums.java.net/jive/thread.jspa?threadID=97

* http://www.csse.monash.edu.au/~bren/JSX.
* Serialize any class very easily to XML.
* While XMLEncoder is AFAIK just JavaBean serializer, JSX is object serialization solution.
* XMLEncoder is a total mess.

--------

ClassCastException should always report incompatible type
http://forums.java.net/jive/thread.jspa?threadID=98

* Default constructor should be deprecated and removed because it is useless: it does not provide information to resolve error.
* public ClassCastException(Class expected, Class offending)

--------

Solve Jar Hell (JDK10?)
http://forums.java.net/jive/thread.jspa?threadID=83

* Force the requirement of version information inside a JAR MANIFEST.MF
* Specify required java package versions.
* WebStart ought to be extended so that it can be used for server side processes and command line applications.
* JVM should support the package management and dependency tracking by default.
* Allow multiple versions of the same packages for management in WebStart.
* Package/jar/module dependecies and requirements should be more precisely specifiable and application/runtime should be able to verify these requirements.

--------

Polish, consolidate and fix bugs.
http://forums.java.net/jive/thread.jspa?threadID=48

* Polish, consolidate and fix bugs.
* Dont see the need for new language features.
* Have a major look at all the old features and fill in the 5% that is missing from many of them.
* Make the Actions framwork so it can handle checkbox items as well (in menus).
* Common buttonmodel so they all change when one changes, with only one event fired.
* More values to customize the components created with an Action - initial state of the checkbox, multiple icon sizes.
* Swing: Add translucent top-level windows.
* Swing: Non-rectanglular windows with hit-area for mouse events.
* Swing: Accelerate everything in Java2D and produce a document that specifies what is accelerated when and on which platforms.
* Swing: Road map for when things will be accelerated.
* Swing: Fix Windows L&F to the spec of Winlaf and JGoodies windows XP.
* Swing: Add/fix really good font support.
* Swing: Use an Integer in the properties to set a cut-boundary over which font-size to AA automatically in a GUI. A value of null would indicate platforma preference and no value at all would (maybe) make all be as today.
* Swing: Add a type of Stroke that draws the inside of a shape and not always a bottom/right offset as BasicStroke does.
* Swing: Add a good (not good enough) docking layout manager (not a docking framwork!).
* Add support for standard plugins via internet auto-loading. A lot can then be plugins instead of in the JRE core download.
* Web Start: Make the warning when running an unsafe JWS application less hostile. It makes me REALLY want to press no, and it's darn ugly.
* Web Start: Add some kind of intermediate trust level that only shows a very small warning, including what functions are requred (when pressing 'details').
* Community: Start a project where people can show of their synth themes and make them easilly downloadable.
* Fix, wrap or redo Calendar/Date.
* Benchmark: Create an application (or start a OS-project) that benchmarks the speed and quality of all types of Java2D operations and saves the inforamtion in an XML-file. This should include driver versions, OS and graphics hardware. It should include testing of OpenGL and fullscreen.
* Stop adding buzz-word features and clean up old code.
* Look at https://gui-commands.dev.java.net, https://jdnc.dev.java.net

--------

Associative class searching
http://forums.java.net/jive/thread.jspa?threadID=85

* Conclusion: use Manifest Service Provider extension mechanism.

--------

New technologies
http://forums.java.net/jive/thread.jspa?threadID=63

* An XML pull parser could be integrated to JAXP (like C# pull parser) see http://www.xmlpull.org/
* Advanced & Raw Socket Support (ICMP, ICMPv6, ping, traceroute, ...)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4727550
* PLEASE don't put any extra libraries in the JRE.
* Improve COM+ component integration.

--------

RFEs vs. Bugs
http://forums.java.net/jive/thread.jspa?threadID=64

* Fix the *social* problem: better communication between Sun engineers and end-users.
* Ability of end-users to include screenshots and other useful attachments when filing issues on BugParade.
* JVM on-the-fly: Availability of a JVM that consists of Java Webstart and its dependencies and *nothing else*. The target size is under 2MB (10 mins of download time for dial-up users).
* SUN negotiate a very nice contract with them (JIRA) which would benefit both organizations to improve bug tracker.

--------

Administration of Libaries
http://forums.java.net/jive/thread.jspa?threadID=75

* If you build an application on top of serveral applications you get big problems with the different needed libaries in classpath.
* There should be also a sharing of the libaries. currently every application brings all libaries with it.
* Having a proper specification for versioning of components, running multiple versions of components (side-by-side execution), etc are a must.
* There must be some way to load a desired version of component from a package instead of depending upon the user specifying X.jar in front of Y.jar in the classpath to ensure that my code runs properly.
* The JAR file that contains a Manifest entry for the package should specify package version for "org.apache.xerces" as 1.2 or greater may be used.

--------

JWS: Installation Package
http://forums.java.net/jive/thread.jspa?threadID=70

* launch WAR file to extract and install automatically on a local machine.
* JDK may have an installation packaging tool for prepare WAR file that may has a feature, setting, build (compile,make JAR,sign, etc.). This tool may be applied to make Applet installation package too.
* Use JNLP for command line applications and services as well.
* More JNLP options on when to update remote and offline apps.

--------

JWS SocketService RFE 4876235
http://forums.java.net/jive/thread.jspa?threadID=55

* Improve Java Web Start
* If you can't make a socket connection from within a secure (unsigned) JWS application you are forcing the majority of applications to require enough permissions to be able to install spyware and viruses.
* Break down security access into groups and categories that can be easily understood in the Java Control Panel.
* Allow Web Start to enforce well established levels of security on both signed and unsigned applications.

--------

Language,Bugs,Documentation,Webstart,Application Stack, + Lots
http://forums.java.net/jive/thread.jspa?threadID=125

(body of the article reproduced here)

#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 I

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jtr
Offline
Joined: 2003-06-10
Points: 0

> Sun will not drop JDK logging because of LOG4J. LOG4J
> was quite mature already when JDK logging was
> introduced. if they did not chose it then, they will
> not do it now. (Not saying you can't just throw away
> JDK logging)

What's wrong with the JDK logging? Having used both, I find them to be about equivalent functionality (at least for my needs). It also seemed to me that the JDK logging was simpler to understand but that might just be because documentation for it was easier to find than log4j.

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

>
> What's wrong with the JDK logging?

IMHO, it was written upside down. Also digitial selection would be better than levels.

Although Log4J has a upside right hierarchy, it is much the same as the JDK logging and still does suffer from having levels instead of digitial selectors. Aside from adaptors, I've not found it to be all that extensible without breaking encapsulation or violating some other fundimential design principle.

monika_krug
Offline
Joined: 2004-10-14
Points: 0

What do you mean by digital selection in this context?

Monika.

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

> Have you ever done real math in Java? :-) You would
> not say this if you have, I suppose.

why do always ask these irritating questions like you are assuming the guy on the other end it an idiot! I'm sure they guy has done real math and by the way.. so have I.

If you are going to change syntax.. for heavens sake, stop and think about it for a bit!

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

I am sorry if I sound offensive. I never assumed the other guy an idiot. My apologies, again, to everyone.

but, please understand that 'doing real math' and doing real math [b]in Java[/b]' is a HUGE difference. I know several guys that are very good at math but never did any in Java.
I never really enjoyed the way we do math in Java, did you? I'd like to improve this. An I realize we need to change syntax.

And yes, I am thinking of it. Sure. But why do you think changing syntax is always a bad thing? I never suggested changing it between 1.2, 1.3, 1,4 releases. Tiger was the good candidate for language change.

Further language changes will follow. i feel Mustang is one of the good candidates (i know I may be wrong; it's not up to me to decide). We will have to catch up with C#, now is the time. After this there will be time to slow the things down for a few years.
It does not make sense to introduce small changes in every little release.
The point is to have all proposals on a single heap so that you can work on them, filter good/bad ones and define a point in the future when you can say: "Now this is the right time for a big change, features are thinked through, well designed and tested, and we have a lot of them to be worth it"

To be able to accept or reject any idea, it have to be suggested first.

Last but not least, I am extending it, not changing :-)

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

We will have to catch
> up with C#,

What makes C# the gold standard and why is Java behind C#?

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

Noooo I am not saying C# si a gold standard. To be honest, I don't like it as much as I don't like Microsoft.
But they seem to have better generics and more sound support for properties. Probably a few others but that's not the point.
Comparing these two features, Java, my personal favourite, choice of my heart, is a piece of crap.

But I am not willing to enter generics debate again (with you). This is over for me.
As for properties support, you're welcome to question me :-)

swpalmer
Offline
Joined: 2003-06-10
Points: 0

> 1) expression
> a + b + (c * a) + b + (c / 2)
>
> 2) now
> a.add(b).add(c.multiply(a)).add(b).add(c.divide(new
> BigDecimal(2)))
>
> 3) proposed
> a add b add (c mul a) add b add (c div 2)

You aren't being fair:
#2 should read:
a.add(b).add( c.mul(a) ).add(b).add( c.div(2) )

no need to spell out "multiply" and "divide" in one version and not the other :)

now look at that right next to the proposed solution:
a.add(b).add(c.mul(a)).add(b).add(c.div(2))
a add b add (c mul a) add b add (c div 2)

The only difference are a few '.' and '()' - is that really worth the trouble? you can even add more white space if you like:
a .add (b) .add ( c .mul (a) ) .add (b) .add ( c .div (2) )

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

About being unfair - you are right, I just used java.lang.Math vs. not yet existing operator functions :-) Unintentional.

Ad. Your second point:

With [i]a.add(b).add( c.mul(a) ).add(b).add( c.div(2) )[/i] you always call methods on objects that must declare them. This might not always be case.

Operator functions are static methods so you can use them with whatever objects you like (even nulls if it makes sense).
If add, div, mul were static methods, result is as follows:

add( add(a,b), mul(c,a), b, div(c,2))
vs. proposed
a add b add (c mul a) add b add (c div 2)

See? To be fair, add() has varargs arguments, it's even shorter :-)
Anyway, this is not as easily translatable to human math as proposed solution, don't you think?

And I believe more complex examples can be found that demonstrate usefulness of the proposed solution far more better than this simple one.

Message was edited by: patrikbeno

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

Have you read that? 'cause it seems like you did not.

It is not about operator overloading (which is explicitly rejected in that proposal). It is [b]alternative[/b] to the operator overloading, maybe called [b]operator functions[/b]

it is [b]not[/b] about changing a.div(b) to a/b
it is about changing a.div(b) to [b]a div b[/b]

think about it, take a look at it. you'll like it

tim12s
Offline
Joined: 2004-02-02
Points: 0

What I want is for the problematic issues of software development made easier. I dont give 2 hoots about a language unless something gets in the way. generics, for, annotations, all great language additions.

I would hesitate to say that that operator overloading is even 50% a benifit to the the Java as the mentioned enhancements. I would definately say runtime generic typesafety would be alot better... hell, even if it had an unreasonable overhead and you could use -enableruntimegenerics (same as -enableassertions).

Barring that, I'd rather have a fully featured Java Web Start than operator overloading.

and "a div b" would probably be a parsers nightmare making it more difficult for tool developers that do refactoring, do source analysis, etc. (Tho if Sun provided an official AST tool...)

I'm not saying its a bad idea, just that there are other things more worth while. I can see only a few cases in source code where operator overloading would be worthwhile which is unlike a FOR loop which is _everywhere_.

And the last thing you want is some fool doing i++ and i-- to open and close a database connection. (no offense intended tony).

When it comes to math libraries and calculation intensive... operator overloading makes sense but operator overloading for this purpose requires a few more language features. The Complex Numbers thread shows an example of just one of those features. There are others.

-Tim

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

I don't think a div b would be a any complication for parsers, they just need an update.

I understand that feature requests as well as any other useful suggestions in this forum should be assigned reasonable priorities. And for me, fixing generics is also far more important than operator functions.

All I wanted is your opinion: is "operator functions" good idea or bad idea? Once we agree on good ideas, we can assign priorities.

tim12s
Offline
Joined: 2004-02-02
Points: 0

It will hardly make my tasks easier or quicker, hence in my opinon its its an average idea. Its a bad idea if it doesnt 'pay off' and it complicates development. (difficult refactoring tools, etc).

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

Have you ever done real math in Java? :-) You would not say this if you have, I suppose.

Perhaps something simple (still no real Math :-)):

BigDecimal a,b,c;

1) expression
a + b + (c * a) + b + (c / 2)

2) now
a.add(b).add(c.multiply(a)).add(b).add(c.divide(new BigDecimal(2)))

3) proposed
a add b add (c mul a) add b add (c div 2)

Now what's better? What's more readable? What's quicker to write? What's more understandable and maintainable? (Ignoring (1) as it is operator overloading which we do not want, except as a explicit math support in Java)

Message was edited by: patrikbeno

tim12s
Offline
Joined: 2004-02-02
Points: 0

Have a look at type 6 in the 'Operator overloading alternative' thread.

nickminutello
Offline
Joined: 2003-08-09
Points: 0

My request is a humble one.

Java Web Start's verbose/trace/logging/diagnostics capability needs much improvement.

When it fails (to launch an app, parse certificate, whatever) there is usually not enough detail in the error message to even begin to help you work out precisely what the problem is. That and the fact that no exception stack traces are displayed :-(

What I would like to see is a console which shows the output of javaws AS WELL as the app I am trying to run. And a more user-friendly way of turning trace/debug level logging in Java Web Start on...

-Nick

jaywwoods
Offline
Joined: 2005-01-25
Points: 0

For the same reasons it is helpful to be able to get a Class instance directly using MyClass.class, it Would Be Nice to be able to get a Field instance using something like MyClass.myField.field and a Method instance using Myclass.aMethod.method.

hlovatt
Offline
Joined: 2003-11-18
Points: 0

RE: immutable and const

If you read the, admittedly very long, thread re. const (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4211070) then you will see that many people including myself are against this but currently can't vote against it (I support negative votes - good idea).

As an alternative take a look at the immutable RFE:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4617197

which is implemented by this Pattern Enforcing Compiler (PEC) compiler:

https://pec.dev.java.net/

(I should own up to some bias - I posted the Immutable RFE and wrote the PEC)

pete_kirkham
Offline
Joined: 2003-06-20
Points: 0

Often you want immutablity at the interface level, but the implementation caches state for performance reasons. Having the compiler enforce that all fields of an immutable class are final prevents this (maybe mark them with transient in lieu of a mutable keyword).

Pete

hlovatt
Offline
Joined: 2003-11-18
Points: 0

What you want, immutability plus under the covers faster version, is a common requirement. The Pattern Enforcing Compiler (PEC), which I wrote, supports this using three patterns: [i]Value[/i], [i]Immutable[/i], and [i]ImmutableValueConversion[/i]. Check out:

https://pec.dev.java.net/nonav/compile/index.html

The idea is that you have an [i]Immutable[/i] type and a companion [i]Value[/i] type that allows changes, e.g. caching. This is similar to the relationship between String and StringBuffer, except that the [i]Value[/i] type has a superset of the interface of the [i]Immutable[/i] type, which isn't true for String and StringBuffer.

The third pattern, [i]ImmutableValueConversion[/i], allows you to convert between the two other classes by copying (thus ensuring immutability). EG for array lists ValueArrayList and ImmutableArrayList are supplied with the PEC:

ValueArrayList va = new ValueArrayList();
va.add( aValue );
ImmutableArrayList ia = (ImmutableArrayList) va.[b]toImmutable()[/b];

The important bit in the above is the call toImmutable (a similar call toValue exists for conversion by copy in the other direction). In your case where you want to keep the [i]Value[/i] type private you would give your [i]Value[/i] type package access and it can cache the immutable version of itself.

All these patterns are enforced by the compiler, let me know how you get on if you try the compiler out :)

tsinger
Offline
Joined: 2003-06-10
Points: 0

Hi hlovatt,

I'm curious, how does your Immutable [b]enforced[/b] immutability? Or do you need a special compiler on top of javac?

Tom

hlovatt
Offline
Joined: 2003-11-18
Points: 0

Hi,

You need a special compiler. It is syntax compatible with standard Java; you mark an immutable class by implementing the Immutable interface.

The compiler is available under LGPL here:

https://pec.dev.java.net/

particularly take a look at:

https://pec.dev.java.net/nonav/compile/index.html

which gives links to the patterns supported and for the immutable pattern:

https://pec.dev.java.net/nonav/compile/javadoc/pec/compile/immutable/Imm...

spetrucci
Offline
Joined: 2004-02-02
Points: 0

Another idea :

Add a non static version of String.format(...) to the String class. That would allow to replace :

int i=1;
String s = String.format("%d", i);

with :

int i=1;
String s = "%d".format(i);

spetrucci
Offline
Joined: 2004-02-02
Points: 0

And another one ... On all the projects I've been working on, Log4J was always used for logging. So now that it is very stable, why not including it in the JDK in place of the current logger implementation ?

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

You have a little bit destructive approach: replace/remove
That's just not feasible

So you cannot add String.format() because it is already static. You could use different name but I think it's not worth it.

Sun will not drop JDK logging because of LOG4J. LOG4J was quite mature already when JDK logging was introduced. if they did not chose it then, they will not do it now. (Not saying you can't just throw away JDK logging)

monika_krug
Offline
Joined: 2004-10-14
Points: 0

But the existing static String.format method uses more than one parameter: There are format(String, Object...) and format(Locale, String, Object...). So it would be possible to have non-static format(Object...) and format(Locale, Object...).

Monika.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

Sure,thanks. I responded primarily to logging replacement and I thought changing format() signature fits the category, too. My fault.

spetrucci
Offline
Joined: 2004-02-02
Points: 0

Hi,

I realize that Log4J was already mature at the time the logging API was designed. I guess that Sun didn't choose to go with Log4J for some (political or license related) reason. I just think this is a missed opportunity.
Anyway, Log4J could still be adapted to integrate (and optionnally replace) tranparently the default logger implementation. Of couse, this would require the agreement/help from the Log4J owners.

Cheers,
Sebastien.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

And what about an alternative to the operator overloading?
http://forums.java.net/jive/thread.jspa?threadID=132&tstart=0

i think it would simplify a lot of things, it would open up many useful options and it would definitely shut up all those voices requiring dangerous pure operator overloading feature.

tim12s
Offline
Joined: 2004-02-02
Points: 0

There are many advancements worthwhile and operator overloading is _definately_ not one of them. A virtue of Java is that what you see is what you get. It makes code simpler to write, simpler to understand. The for (X x:xx) improves read/write, a.div(b) vs a/b is a minor advancement. Compared to other evils, worth it? hell no.

tsinger
Offline
Joined: 2003-06-10
Points: 0

> A virtue of Java is that what you see is what you get.
> It makes code simpler to write, simpler to understand.

Tim, I agree. Maybe we should see every RFE under the aspect, that Java is and should stay a "WYSIWYG-language". Well, it can be more expressive here and there (e.g. const or design-by-contract), but for example [code]new A()[/code] should always call the constructor of A, not a factory method.

Tom

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

I believe runtime support for generics is one of the most important RFEs
http://forums.java.net/jive/thread.jspa?threadID=92&tstart=0

What do you think? You did not attend discussion, but have you read it?

And what about properties support?
http://forums.java.net/jive/thread.jspa?threadID=104&tstart=0

tim12s
Offline
Joined: 2004-02-02
Points: 0

I've added runtime generics enforcement. I read it previously, its a very good discussion but sure there is a reasonable implementation/backwards compatible issue somewhere close to the JVM at byte code level. Considering that it came through JCP, one should understand why something as straight forward as this was not caught previously. I'm sure it must have been discussed.

Still not convinced about the benifits to annotated properties.

I've commented on both in those discussions.

Message was edited by: tim12s

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

I have added proposal in related discussion.
See http://forums.java.net/jive/thread.jspa?messageID=4067#4067

I think it is feasible and improves JavaBeans modelling a lot.
I would like to add this thread into your 'Best Threads So Far' list (I think it deserves it, no matter what Sun does). Would you mind?

Message was edited by: patrikbeno