What do I need in JDK ?

I'll put some staff that I found that are much problem from time to time for me.

• Lack of methods in File class...
• String Comparator...
• Thread Statics...
• Add .shrink() for StringBuffer & StringBuilder...
• 1st lvl type validation in standard Generics...
• Generics variables...
• Support for method to be able to return more than one variable...
• Extended printStackTrace...
• Read-Only Arrays...
• 'forget' keyword...

Add to File class:

• .copy(File)
• .compareFileData(File)
• . ...

String Comparator

String Comparator is horrible, it's provide much useless information. Who need 'this.charAt(k)-anotherString.charAt(k)' mixed with 'this.length()-anotherString.length()' ?
Let's see other way to implement comparator:
stringA.compare5StateTo(stringB)

• return -2 if stringB is greater than stringA
• return -1 if stringB start with stringA
• return 0 if stringA equals stringB
• return +1 if stringA start with stringB
• return +2 if stringA is greater than stringB

Now time I need perform 3 operations to obtain same target.

Thread Statics

Static is global, but allow to make thread static would allow to remove 10~100% synchronization blocks. But it's really hard task and need to be deeply considered. Main problem is to prevent all thread-static data to be created with each thread, and make it available on demand only. Resources pool with auto–pinning to thread would be some solution as well.

Add .shrink() for StringBuffer & StringBuilder

Now time array inside of this Objects can only increase with it's size. This can be problem if happen that for one moment some one will put there a lot of data remove it and skip the object for new one.
Scenario:
We have 100 StringBuffer shared between threads (so we cannot dispose memory).
In 99,9..% of time StringBuffer store 1kb of data and in 0,001% there is 1mb of data.
In that case after some time there will be 100Mb unnecessarily allocated memory.
Other solution is conditional decreasing array size on .remove() (I prefer that).

1st lvl type validation in standard Generics

Personally I used to pass Class<? super ComponentType> in constructor. This solution can to be done easily. With no backward impact.
This cannot be overestimated as one of the best solution to prevent stupid bugs.
Second solution is to add validators on .add(...). More powder full but not as easy to use as previous one.

Generics variables

We have methods, classes, why there are no variables?

Support for method to be able to return more than one variable

Sample:

public static (int:index, double avg) some(...){
  if (isRequested(index)) index = binarySearch(...);
  if (isRequested(avg)){
    ...
  }
}

public static main(...){
  int index;
  index=some(...).index;
  double avg;
  (index=.index,avg=.avg)=some(...);

  some(...).{//here we have access to returned values here
    if (.avg>0){
      ...
    }
  };
}

Notice that isRequested() is a method which tells us if parameter needs to be returned.

Simple tuples are bad, the same as a return by reference because you need to remember parameters' sequence. That's why, even if we are able to return more than one value, we may have implemented the same method in a few different ways (and it's not so rare) depending on what we need.

You may do not see the power of this solution, however, when you analyze the given case you will see that the return values do not need to be counted if a used method is not requested for them.

Creating a new Class for that purpose is not a solution as well. If you analyze this you will see that it is not so rare to define unnecessary classes for each method ( or most of them) that do not allow us to tell if we need a full result or only part of it.

Have you ever wandered what you return when you add many elements to container? It really would be nice to get back:

Did even wander what would u return in case that when u add many elements to container. What would be nice to get back?

• number of added elements
• number of not added elements
• list of added elements
• list of not added elements

Of course, overkill might be a bad solution, as always.
I will describe it in more details on free time.

Extend printStackTrace

Allow to print stack trace only from throw exception point to exception handling point.

Read-Only Arrays

It's really hard to pinpoint what solution would be best.
At first I wander about 'context' access like:

Type[] readOnly =array.getReadOnly(from,to);
array[from] = t;
if (readOnly[0]==t) is always true

This would be peaty powder full solution, and it would allow to write more secure programs. Unfortunately every operation on arrays could bring unexpected problems if some one would use base array as buffer. Is that clear?

System.arraycopy(readOnly, srcPos, array, destPos, length);

We need check if readOnly and array point same space!

Other solution is about giving always read only arrays:

Type[] readOnly =array.copyAsReadOnly(from,to) array[from] = t;
if (readOnly[0]==t) can be false

'forget' keyword

with 'forget':

String data =readLine();
data = operate(data);
boolean isOk = data.contains(“contains”);
forget data;
// here we do not have access to data object

now time:

boolean isOk;
{
String data =readLine();
data = operate(data);
isOk = data.contains(“contains”);
}
// here we do not have access to data object