What feature that you wished Java 7 had that isn't in?

[joe taka]

Hi Jeff Freisen,

What feature that you wished Java 7 had that isn't in?

Regards,
Taka

[Campbell Ritchie]

Welcome to the Ranch

[James X Peterson]

Hi,

When i worked in .net i thought that java doesnt have feature i.e in case statement we cant give strings. but in java 7 the y have included them thanks for that.

Regards,
James

[Jeffrey Friesen]

Hi Joe,

I would love to have seen collection literals (e.g., empList[10] instead of empList.get(10)) included in Java 7. Unfortunately, it doesn't look like this feature will make it in Java 8 -- see http://openjdk.java.net/projects/jdk8/milestones. Perhaps it will be included in Java 9.

All the best.

Jeff

[joe taka]

Hi James and Jeff,
Thanks for the reply.

I liked the delegate function reference in dot net..
will the closure cover that?

[R. Grimes]

I"m a simple guy. My wishes are small, since I don't think I'll ever come close to using the full power of Java as it already exists. But, I really hate having to do repetitive stuff like

if (s.trim().equals("some string"))

There's already equalsIgnoreCase. How about equalsIgnoreWhitespace? Or, equalsIgnoreCaseAndWhiteSpace?

Also, I hate having to to check strings for both null and empty. So, instead of

if ((s == null) || (s.isEmpty()))

s.isNullOrEmpty()?


Yes, I know there are Util packages out there that does that kind of stuff, but this is pretty basic stuff and should come with the basic JDK. Simple things like this can remove a lot of clutter. I'm always amazed at how Java makes hard things simple, and simple things overly complex or verbose to achieve.

Ron

[joe taka]

yeah i agree also, if they would have out of the box most often used utility libraries would be great..
like those functions you mentioned could be put as a static functions in the String class or something..

[Rob Spoor]

R. Grimes wrote:s.isNullOrEmpty()?

That would cause a NullPointerException if s is null, because you can't call any (non-static) methods on a null reference. It would be better if an isEmpty(String) method made it into a java.util.Strings utility class, like how they introduced java.util.Objects in Java 7.

[R. Grimes]

Rob Spoor wrote:

R. Grimes wrote:s.isNullOrEmpty()?

That would cause a NullPointerException if s is null, because you can't call any (non-static) methods on a null reference. It would be better if an isEmpty(String) method made it into a java.util.Strings utility class, like how they introduced java.util.Objects in Java 7.

Makes sense. Hadn't thought of that when I was throwing out the ideas last night. But, yeah, if s is null, you can't call a method off of it. So, your way is a better fit. I guess my main point is, like Joe said, a lot of us use some pretty common StringUtil methods from non-core packages. Seems like some of them, if not a lot of them, ought to be incorporated in the jdk.

[Mohamed Sanaulla]

Wish Project Lambda(http://openjdk.java.net/projects/lambda/) was in Java 7, but its a huge change and being included in Java 8 leaves me with no regrets.

[Abhay Agarwal]

I wish if there were insertionSort, bubbleSort and other such algorithms (like heapSort etc) present out of the box in Java 7 or Java 8 API

~ abhay

[Deepak Lal]

wish if there were insertionSort, bubbleSort and other such algorithms (like heapSort etc) were present like in a user friendly API interface.we could use the api and do our common implementation

[Abhay Agarwal]

@Deppak - I agree with you. These sorting algorithms are so common. may be there is some strong reason behind not implementing these sorting algo in any utility class in Java API.

[Campbell Ritchie]

Abhay Agarwal wrote: . . . not implementing these sorting algo in any utility class in Java API.

As they are not implemented by this method, for example?

They use the most efficient sorting algorithms available, giving Ologn performance, rather than bubble sort or selection sort which run in On² time. If Gosling &c had implemented a bubble sort algorithm, they would have faced years of ridicule for it!

[Stephan van Hulst]

I still want a method that can tell me whether a String can be parsed to an int. I also want methods that can convert primitive arrays to collections and vice versa.

I also think having annotations that indicate preconditions and invariants would be nice. I believe an annotation @NotNull is coming up, but I can picture that it would be nice to be able to do something like this:

@Require(list.size() > 3)
public void process(List<Foo> list) {
  // process list
}

Instead of:

public void process(List<Foo> list) {
  if (list.size() <= 3)
    throw new IllegalArgumentException();

  // process list
}

[Campbell Ritchie]

That looks like the old REQUIRE and ENSURE keywords in the Eiffel language.

[Stevens Miller]

joe taka wrote:What feature that you wished Java 7 had that isn't in?

Unsigned bytes.

I'd trade every single new feature it does have for unsigned bytes.

[Pat Farrell]

Stevens Miller wrote:Unsigned bytes.

Would you accept unsigned octets as a more well defined equivalent?

I grew up on machines that had variable byte sizes. All of the RFCs and ISO crypto standards are written for unsigned octets. So I'd be happier with the name octet
over byte.

Other than the name, I agree, the lack of unsigned bytes is a royal PAIN.

[Stevens Miller]

Sure, call it whatever you like.

But, asking for "octets" of any kind would be adding a new data type to the language. Java already has bytes. I want the same primitive, by the same name, just without a sign.

[Pat Farrell]

Stevens Miller wrote: But, asking for "octets" of any kind would be adding a new data type to the language. Java already has bytes. I want the same primitive, by the same name, just without a sign.

But they are signed bytes.
I don't see how you could have byte[] or Byte[] and have it either be signed or unsigned.

Obviously, calling it anything will break some programs. Which gets to my standard rant that backward compatibility is over rated.

[Paul Clapham]

Pat Farrell wrote:I don't see how you could have byte[] or Byte[] and have it either be signed or unsigned.

Sure you could. You know that it's the same 8 bits in the byte when you store it, it's when you use it that you can treat it as signed or unsigned. So it isn't a datatype, it's some kind of annotation which says "treat the bytes as unsigned in this calculation". Obviously I've only spent 30 seconds on this so I haven't thought it out, but that's how I see it.

[Stevens Miller]

Good point. I guess what I am really asking for is not "unsigned bytes," but an "unsigned" primitive type modifier.

You know, like C++ has...

and C has...

and has had...

for about the last seven-hundred billion, trillion years.

[Pat Farrell]

Paul Clapham wrote: it's when you use it that you can treat it as signed or unsigned. So it isn't a datatype, it's some kind of annotation which says "treat the bytes as unsigned in this calculation".

What other datatypes use annotations to control things like overflow or the results of addition.

I think you'd have to have the annotation on the declaration and every usage, which will quickly become way ugly.

Again, the specs say octets, not bytes. Is a legacy curse from the PDP-11's implementation of C that we think of them as 8 bits. EBCDIC bytes are 9 bits long.

[Pat Farrell]

Stevens Miller wrote:You know, like C++ has...and C has...for about the last seven-hundred billion, trillion years.

I've told you a million times not to exaggerate.

The earliest known records of C come from 1969. Its barely 45 years old.

[Paul Clapham]

Pat Farrell wrote:

Paul Clapham wrote: it's when you use it that you can treat it as signed or unsigned. So it isn't a datatype, it's some kind of annotation which says "treat the bytes as unsigned in this calculation".

What other datatypes use annotations to control things like overflow or the results of addition.

I think you'd have to have the annotation on the declaration and every usage, which will quickly become way ugly.

Yes, well I did say I didn't have a full design worked up. I expect that such an annotation would normally be used at the method level or even at the class level by people who wanted unsigned byte calculations.

[Stevens Miller]

All I want is the existing byte primitive to be available in an unsigned form. Yes, "byte" doesn't mean any particular number of bits when you are talking about computer architectures (though I'm puzzled by the assertion that "EBCDIC bytes" are nine bits long; while I have never heard of EBCDIC bytes, EBCDIC characters are coded in eight-bit units). But, in Java, "byte" means an eight-bit primitive integer. Alas, owing to a design decision I have never understood, Java bytes are always signed, no exceptions.

C may not be as old as I alluded, but I am reminded of this saying:

Leopold Kronecker wrote:God created the natural numbers. All else is the work of man.

While there is debate about whether or not the natural numbers include values less than zero, I would tend to expect that God's programming language would not require them. Neither, imho, would God's Java.

[Campbell Ritchie]

God wrote:Surely men of low degree are vanity,
  and men of high degree are a lie:
to be laid in the balance,
  they are altogether lighter than vanity.

From Psalm 62: 9.

That implies that God uses negative numbers to me: lighter than vanity nothing
The natural numbers (ℕ) run from 0…+∞ inclusive and do not include negative numbers. If you want negative numbers, try the integers set (ℤ).

[Campbell Ritchie]

Pat Farrell wrote: . . . The earliest known records of C come from 1969. Its barely 45 years old.

But it used 16‑bit ints and

seven-hundred billion, trillion

…was truncated by the cast to 45

My, this bit of the thread should have come out on 1st April!

[Campbell Ritchie]

I agree that unsigned bytes would have been a lot easier to work with.

[Stevens Miller]

Campbell Ritchie wrote:I agree that unsigned bytes would have been a lot easier to work with.

There. Campbell Ritchie agrees. Thus we know that God is right.

[Campbell Ritchie]

You would end up having to write
int i = 0 | bytes[j]; or even 0x00ff & bytes[j]

[Rafael Prado Oliveira]

Take a look at http://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/StringUtils.html

this might fullfill your request!!!

isEmpty

public static boolean isEmpty(String str)
Checks if a String is empty ("") or null.

StringUtils.isEmpty(null) = true
StringUtils.isEmpty("") = true
StringUtils.isEmpty(" ") = false
StringUtils.isEmpty("bob") = false
StringUtils.isEmpty(" bob ") = false

NOTE: This method changed in Lang version 2.0. It no longer trims the String. That functionality is available in isBlank().

Parameters:
str - the String to check, may be null
Returns:
true if the String is empty or null
isNotEmpty

public static boolean isNotEmpty(String str)
Checks if a String is not empty ("") and not null.

StringUtils.isNotEmpty(null) = false
StringUtils.isNotEmpty("") = false
StringUtils.isNotEmpty(" ") = true
StringUtils.isNotEmpty("bob") = true
StringUtils.isNotEmpty(" bob ") = true

Parameters:
str - the String to check, may be null
Returns:
true if the String is not empty and not null
isBlank

public static boolean isBlank(String str)
Checks if a String is whitespace, empty ("") or null.

StringUtils.isBlank(null) = true
StringUtils.isBlank("") = true
StringUtils.isBlank(" ") = true
StringUtils.isBlank("bob") = false
StringUtils.isBlank(" bob ") = false

Parameters:
str - the String to check, may be null
Returns:
true if the String is null, empty or whitespace
Since:
2.0
isNotBlank

public static boolean isNotBlank(String str)
Checks if a String is not empty (""), not null and not whitespace only.

StringUtils.isNotBlank(null) = false
StringUtils.isNotBlank("") = false
StringUtils.isNotBlank(" ") = false
StringUtils.isNotBlank("bob") = true
StringUtils.isNotBlank(" bob ") = true

Parameters:
str - the String to check, may be null
Returns:
true if the String is not empty and not null and not whitespace
Since:
2.0

But for the compare "equalsIgnoreCaseAndWhiteSpace" couldn´t find it. but you could do a StringUtils.equalsIgnoreCase(StrA.trim(),StrB.trim())

R. Grimes wrote:I"m a simple guy. My wishes are small, since I don't think I'll ever come close to using the full power of Java as it already exists. But, I really hate having to do repetitive stuff like

if (s.trim().equals("some string"))

There's already equalsIgnoreCase. How about equalsIgnoreWhitespace? Or, equalsIgnoreCaseAndWhiteSpace?

Also, I hate having to to check strings for both null and empty. So, instead of

if ((s == null) || (s.isEmpty()))

s.isNullOrEmpty()?


Yes, I know there are Util packages out there that does that kind of stuff, but this is pretty basic stuff and should come with the basic JDK. Simple things like this can remove a lot of clutter. I'm always amazed at how Java makes hard things simple, and simple things overly complex or verbose to achieve.

Ron

[Rafael Prado Oliveira]

Same org.apache.commons.lang.StringUtils have something like that..

isNumeric

public static boolean isNumeric(String str)
Checks if the String contains only unicode digits. A decimal point is not a unicode digit and returns false.

null will return false. An empty String (length()=0) will return true.

StringUtils.isNumeric(null) = false
StringUtils.isNumeric("") = true
StringUtils.isNumeric(" ") = false
StringUtils.isNumeric("123") = true
StringUtils.isNumeric("12 3") = false
StringUtils.isNumeric("ab2c") = false
StringUtils.isNumeric("12-3") = false
StringUtils.isNumeric("12.3") = false

Parameters:
str - the String to check, may be null
Returns:
true if only contains digits, and is non-null

Stephan van Hulst wrote:I still want a method that can tell me whether a String can be parsed to an int. I also want methods that can convert primitive arrays to collections and vice versa.

I also think having annotations that indicate preconditions and invariants would be nice. I believe an annotation @NotNull is coming up, but I can picture that it would be nice to be able to do something like this:

@Require(list.size() > 3)
public void process(List<Foo> list) {
  // process list
}

Instead of:

public void process(List<Foo> list) {
  if (list.size() <= 3)
    throw new IllegalArgumentException();

  // process list
}

[Stevens Miller]

I'd like something that automatically deregisters listeners when they otherwise go out of scope. Right now, if I add a reference to a listener via EventListenerList.add, I must later call EventListenerList.remove to disable further notifications. It would be nice if listeners simply stopped receiving notifications when they became subject to garbage-collection (which, so long as an EventListenerList object is holding a reference to them, never happens).

Visual Basic 6 (the last version before .NET) had something like this. Objects could call "RaiseEvents," which notified all other objects that had references to them and which had them "with events." When those listeners went out of scope, any subsequenct RaiseEvents calls just didn't involve them.

[Paul Clapham]

I use a Set<WeakReference<Listener>> for that. Then to notify all the listeners:

for (WeakReference<Listener> reference: listeners) {
	Listener listener = reference.get();
	if (listener != null) {
		listener.eventOccurred(event);
	}
}

[Stevens Miller]

Paul, as I understand it, that makes the referent eligible for garbage-collection, but it doesn't remove the referent from your listeners collection until (if ever) some later time. What would happen in that case if your listener shouldn't have its eventOccurred method called, but your code fragment were to run? For example, suppose a listener opens a file, updates it, and closes the file when your event occurs. Does your method guarantee that this won't happen after your listener has only weak references held on it?

[Paul Clapham]

Yes, that's what a WeakReference does. When its referent is eligible for garbage collection, the get() method will return null instead of the referent. At least, that's how I understand it.

Although, reading the API docs, it appears that there might be a gap between the listener becoming weakly reachable and the garbage collector noticing that, and during that gap perhaps the listener might be called superfluously. That was what you meant, wasn't it? But I don't think you can avoid that because nothing in the language enables you to interact with the garbage collector any more tightly than what WeakReference already does.

Which I guess gets us back to what you originally asked. It seems you want a deterministic interface with the garbage collector, instead of just allowing the garbage collector to lounge around in the background doing its own thing.

However if you had a garbage collector which worked via reference counting, it wouldn't be that hard to do what you described VB 6 as doing. It's been decades since I used VB, and back then it was VB 5, but I'm pretty sure it used reference counting, since I recall discussions about having to write code to clean up objects with circular references.

[Stevens Miller]

Paul Clapham wrote:Yes, that's what a WeakReference does. When its referent is eligible for garbage collection, the get() method will return null instead of the referent. At least, that's how I understand it.

That's my understanding as well, but I think that means the get method has to add some logic: you don't get that null from a feature of Java as a language; you get it because collections treat weak references specially. (I may be talking completely out of my backside here, as I am inferring this from a one-page treatment of WeakHashMap, which states that it is the class itself that, upon reading the weak reference from the GC's queue of collected weak references, removes the reference from the collection. I take that to mean the reference remains in the collection at least until the GC collects it, which doesn't happen at any time certain.)

Although, reading the API docs, it appears that there might be a gap between the listener becoming weakly reachable and the garbage collector noticing that, and during that gap perhaps the listener might be called superfluously. That was what you meant, wasn't it?

Precisely.

But I don't think you can avoid that because nothing in the language enables you to interact with the garbage collector any more tightly than what WeakReference already does.

Which I guess gets us back to what you originally asked. It seems you want a deterministic interface with the garbage collector, instead of just allowing the garbage collector to lounge around in the background doing its own thing.

Well, I would put that the other way 'round: I want a signaling mechanism (what VB6 did with its "RaiseEvents" statement) that is independent of the GC: one that is built directly into the language spec itself. But, Java hasn't got events built into it. As far as I can tell, all the listeners, events, and so on, are implemented in code, not in the language spec. It's a nice implementation, and can be done in other languages as well, but it's a bit disappointing that a managed language allows for, effectively, this kind of memory leak, when a pissant, rinky-dink, chicken-sh*t quaint old language like VB6 had a way out of the dilemma in the last century. I suspect one could even code one's way around this issue if Java had destructors, since, at least, the listeners could unregister themselves in their own destructor methods (if they knew where they had been registered, which is hardly a necessary condition). But, for reasons I actually don't know, Java doesn't have destructors, either.

This is the kind of thing that, for those of us who were rather smug about always matching our malloc calls and our free calls, leads to down-the-nose views of managed languages. However, I shall not indulge myself that way here at this time.

However if you had a garbage collector which worked via reference counting, it wouldn't be that hard to do what you described VB 6 as doing. It's been decades since I used VB, and back then it was VB 5, but I'm pretty sure it used reference counting, since I recall discussions about having to write code to clean up objects with circular references.

Yeah, VB used counts, I believe. But, even that wouldn't save you in Java, since the reference is actually held in a collection by the EventListenerList (or whatever it is one uses to keep one's list of listeners). Even a weak reference would be kind of messy, since code would still have to handle it, or else the language would somehow have to know that objects with only weak references weren't- no, I'm not even going to finish that statement. I see no way that a language at run time can "manage" a weak reference for all purposes (thus the queue mentioned in the API docs).

An aside: I bring this up because my wife is a VB6 programmer. She got a new job recently. It requires that she manage a lot of legacy code, all written in VB6. That code has "RaiseEvents" all over it. She asked me how a modern language like Java handled the same thing. The results of my investigations lead me to this discussion we are having now.