This week's book giveaway is in the Java in General forum.
We're giving away four copies of Event Streams in Action and have Alexander Dean & Valentin Crettaz on-line!
See this thread for details.
Win a copy of Event Streams in Action this week in the Java in General forum!

Justin Coombs

Ranch Hand
+ Follow
since Oct 10, 2012
Justin likes ...
Android Chrome Windows
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
10
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Justin Coombs

Thanks for all your helpful input.

I'm seeing how powerful this can be, in terms of building robust code. The type "T" or "O" (or any placeholder) can be used in a generics class declaration, and that placeholder can be used to form additional contracts about what the runtime type must also have a contract for.

Here I declare an interface with a type parameter O. The interface also extends Comparable<O>, which means that any type which implements the BNBObject<O> interface must also implement Comparable<O>. And in various places in the declaration of that interface I use the type parameter O, in the context of types for method parameters. For example one of the methods of the interface is



So, if O at runtime is of type Taxon, Taxon must also be comparable to other Taxon objects. If O at runtime is of type Integer...well that wouldn't happen because although Integer implements Comparable it is not a class which implements the BNBObject interface and wouldn't compile. Which is important, since contracts (interfaces are very commonly referred to as a type of "contract") are very important in Java. Integer wouldn't know how to createNode() and return a BNBTreeNode because it doesn't know how! The javadoc certainly has no entries in the Integer class for anything like a BNBTreeNode. And by setting up this class declaration, it's guaranteed at compile time that all BNBObject's know how to createNode and return a BNBTreeNode of a type which is exactly...it's own type, at runtime. You've set that up in your interface's public BNBTreeNode<0> createNode().
2 years ago
seriously...need an edit button...either that or I need to be a subclass of PerfectRobot

In this case, that would be a pointer/reference/(memory address) to a HierarchicalObject in my implementation, as opposed to a pointer/reference(memory address) to a subclass of HierarchicalObject, as in Paul Clapham's suggestion.



should read

In this case, that would be a pointer/reference/(memory address) to a subclass of HierarchicalObject, as in Paul Clapham's suggestion, as opposed to a pointer/reference(memory address) to a to a HierarchicalObject, as in my implementation



I had them backwards...
2 years ago

Paul Clapham wrote:

Not quite; what you actually want is this:



In your attempt you ended up declaring HeirarchicalObject as a generic type, but you based it on HeriarchicalObject as a raw type.




This makes sense to me I believe.

If I say T extends HierarchicalObject i'm defining HeirarchicalObject to have a bounded type parameter of HeirarchicalObject type. You could say in a sense I'm defining a pointer to something that holds the data and actions of what a HeirarchicalObject has and does.

But in your suggestion, with

Paul Clapham wrote:

, with emphasis on the red part of "<T extends HeirarchicalObject <T>>", I'm telling HierarchicalObject that it's implementing type should be a pointer/reference(memory address) to the implementing type, rather than a pointer/reference(memory address) to the "raw type". In this case, that would be a pointer/reference/(memory address) to a HierarchicalObject in my implementation, as opposed to a pointer/reference(memory address) to a subclass of HierarchicalObject, as in Paul Clapham's suggestion. The result, if I understand correctly, if I use Paul's suggestion, is that my "pointer" would be to an object of a subclass type, with, most likely, additional instance variables and methods which I may find useful, especially for the fact that they can be accessed in a generic way.

Is this all correct?
2 years ago
another edit

replace all "Heirarchical" with "Hierarchical". (Yes, its a key word in software and if used in software, or anywhere, should be spelled correctly, thanks so much)...i may have refactored out with the wrong spelling from the beginning...

So, it does in fact make sense to form a contract this way, using generics, provided the info about the implementing classes having particular rules and the want for those rules to be handled generically?
2 years ago
In which case, I would need to pass in the subclass trying to type, so I suppose in my case I might want to change my class definition to look like this:?



This change would of course cause some need for refactoring and/or editing. But if T is the type of HeirarchicalObject, then there would now be the reference to the type with the particular setParent() implementation im looking for in the client code whilst still being able to instantiate HeirarchicalObjects and use setParent() without need for consideration of whatever T is. T is passed in to the generics class and so it's version of setParent() can be accessed.
2 years ago
Gah, I really dislike that there's no edit button.

EDIT**
In the generics situation I'm looking for, I believe the last comment about abstract is incorrect.
I would want to implement this logic in generic HeirarchicalObject setParent(P parent) and use P's methods and instance variables. It would not be abstract it would have to be concrete in the generic class, as far as I can tell

This example, taken from the javadocs illustrates...


The intValue could be called by the generics class because the generics class knew what it's subtypes were, and knew a call to intValue was possible, but I guess it's up to "T" to decide what "getIntValue()" really does

This is similar to what I'm trying to achieve...where isEven, in this case, is similar to setParent, such that I can call setParent on an HeirarchicalObject and let HeirarchicalObject defer to it's instantiated subtype, the logic for that
2 years ago
Hi Henry, thanks for your reply.

I want to be able to, elsewhere in code, use HierarchicalObject as a paramater and return type, and access it's unknown implementing types (as far as the other client code is concerned). That way if HeirarchicalSubclass1 has a setParent() different than HeirarchicalSublass2, the client code can still instantiate 2 HeirarchicalObjects and call setParent() without having to worry. Otherwise, I foresee some kind of heavy use of the "instanceof" operator, which is heavily frowned upon.

I do know my subtypes, as far as the code I'm writing for the subtypes...but then I'm writing other code which uses the subtypes. I want that other code to do things like iterate over HeirarchicalObject subtypes in clean code, and in general I want everything to keep things DRY, and again, avoid use of the instanceof operator.

If I instantiate elsewhere in the code as a non-generic HeirarchicalObject, I will only have access to the methods and properties of the HierarchicalObject object, but if I use generics, I can instantiate the generic implementations and I will have access to do things like setParent() in client code without worrying about which type im trying to set the parent of, as long as I configure my HeirarchicalObject to have an abstract setParent(), to properly set the contract that the subclass should be implementing it.

Am I on the right track here? Is this actually a type of use case for generics, or do I still need to read up a bit more?
2 years ago
Constructor should be protected, as a side note (can't seem to find a way to edit)**

Please note that this question isn't about fixing my code; My goal really would be to use this snippet, coupled with my description of what I intend to model, to further enhance my understanding of generics.

The answer to the question could likely be a refactoring, which could be very enlightening, or a simple syntax fix, which would be great too, or something else entirely, which is fine as well.

The overall goal is that I want to be able to learn from this example to more deftly leverage generics. What might I need to know to better understand generics in the first place? Things of that sort.
2 years ago
I would like to seek out a bit of clarification about Generics and Bounded Type Parameters.

After reading through the java tutorials on generics, and specifically the sections about Generic Types and Bounded Type Parameters. I think I have a pretty good understanding, but I'm stuck about how to leverage generics to implement a particular concept I have.

I'm trying to create an abstract class, which I've named HeirarchicalObject, which essentially models an object that has a parent of any type which subclasses HeirarchicalObject, and, if possible (this is what's troubling me), an ArrayList of children, which are subclasses of type HeirarchicalObject

Here is the code I have, which is my attempt at using generics and bounded type parameters to write generic, or in this case [semi]-generic code (since there are restrictions on what types can be a HierarchicalObject, specifically, types which subclass HeirarchicalObject):




What troubles me is the class definition. It says that a heirarchical object has a P parent and a C child, but I intend for it to say that it has a P parent and a ArrayList of C children.

When I try to use the following change, it is not valid.



How can I, if at all, change this code to reflect what I intend?
2 years ago
This is a great reply, thank you! Makes sense that the version compatibility is the issue...I'd just figured that NetBeans or the Compiler would automatically set my application to the most backwards-compatible java version based on which java packages I imported and which syntax I'd used.

I think I'm going to have to learn about how to create manifest files because I can't run the application when it is compiled via the following commands:



The output from the jar command says that a manifest was added but when I try to run it it says that there's no main manifest attribute. It certainly wouldn't hurt to learn about manifest files...I figure I need to point to the class containing the main method(which is FileOrganizer.java - its a one-class tiny program), but this is just speculation.
Serves me right for relying on NetBeans to magically do the work for me :P
5 years ago
I wrote a simple program in Java and exported it to a jar file via Netbeans' "build" function which generates a jar file for the current project. On my Windows7 machine it ran fine when I tried to launch it via cmd and also by double clicking the icon. But I wanted to test out its compatibility so I copied the jar file onto a USB and pasted it to the desktop of an OSX machine (running Mavericks) and I cannot launch the program. When trying to launch it via the terminal I get the following stack trace:



Does anyone have any insight into why this isn't working? This is a bit beyond my scope, but it looks like its an issue with the java versions in either machine...the mac has 1.7.0_51 and the windows7 machine it was compiled on has version 1.8.0_05. The code definitely does NOT use any features specific to version 8...if it is indeed something to do with java versions, then what the heck happened to "write once, run anywhere"?
5 years ago
I'm currently reading a Java textbook, so a couple topics come to mind

  • Generics
  • Enum types


  • I found learning UML diagramming - although seemingly boring at first - to be extremely catalytic in understanding OOP more concretely.
    Also, although not Java, learning Binary and the OSI model have been really valuable supplementary studies. Especially binary - once you understand binary thoroughly, all primitive data types, ascii values and certain operators like bitshift suddenly become demystified. Boolean algebra helps too!

    EDIT:

    Two fantastic reads:

  • Head First Java
  • Deitel Developer Series' Java for Programmers, 2nd Edition


  • The former is in my opinion THE ONLY book for beginner programmers, and the latter is more down-to-business. In Head First Java you will get great analogies, diagrams, and a fun read, yet still learn a great deal, however there's not a great deal of code. (Understandably, keeping the target audience in mind). In the Deitel Developer Series you won't get many diagrams at all, but you will get a ton of very well written, clean code which is always thoroughly commented and then further explained in paragraphs walking you through the code. All or nearly all of the topics you have listed are included in that Deitel book. Both titles have been a delight to learn with.
    5 years ago
    Thanks Joanne. After seeing your code snippet with the more friendly syntax, and reading a bunch of enum examples, especially oracles own example at the docs I have a much better comprehension.
    5 years ago
    Thanks for the replies.

    So I took your advice Campbell Ritchie and tried to write out the code for the enum, but I'm confused about the syntax for enum classes. Here's what I have



    And then I needed to adjust the Paddle code by initializing variables and changing updateYVel()...







    What confuses me most is the parameters for an enum, because the presence of a constructor leads me to believe that I should be instantiating them, and in this case I should be passing it an int. But after looking up more on enums, I discovered they are always implicitly static and cannot be instantiated as a new object. So mostly its the constructor that throws me off because in my mind I've always associated constructors with instantiating new objects. Also, the syntax of using the parentheses beside the enum constants, such as NORTH(1) is confusing. It seems as though the parameter list of the constructor must match the parameters in the parens beside the enum constants themselves in both quantity and type, which is understandable, but it's so weird because in client code, there is no parameter passing - in class Paddle I simply declare direction = Direction.STATIONARY!. Simple constants are so much easier to understand. But now that the changes have been made, I can see the benefit...the switch statement has been completely eliminated from the whole project and yet it all works exactly the same!

    Nevertheless, even after this big post, if there's a more proper way I should be doing the enum class, I'd appreciate further correction
    5 years ago
    I am a little bit unsure whether I have the right idea with enums, so I'll post a bit of sample code and ask for your feedback about whether this is a proper usage of enums.
    Say I have a class "Paddle" in a Pong game and I want to have 3 enums to model the direction in which a paddle is moving - NORTH, SOUTH, STATIONARY. Would the following code make sense? If not, please try to explain how I'm going about it the wrong way



    And the enum class...


    As you can see, I call updateYVel() in the methods setYSpeed() and setDirection() because a change in speed and a change in direction would both affect the velocity. The yVel is multiplied by either 1 or -1 in order to be used in the coordinate system of a java GUI, and naturally a stationary object should have it's speed and yVel set to 0. Does this make sense or should I be going about it a different way?
    5 years ago