Package by feature or layer?
2,374 views
Skip to first unread message
Christian Beil
Jun 13, 2009, 7:15:17 AM6/13/09
to The Java Posse
Hi all,
John O'Hanley (http://www.javapractices.com) has an interesting
article about harmful Java practices:
http://www.javaworld.com/javaworld/jw-07-2008/jw-07-harmful-idioms.html
What is your opinion on that? I'm especially interested in what you
think about structuring packages? Do you package by layer (ie
dao,service,controller,...) or do you package by feature?
Cheers,
Christian
John O'Hanley (http://www.javapractices.com) has an interesting
article about harmful Java practices:
http://www.javaworld.com/javaworld/jw-07-2008/jw-07-harmful-idioms.html
What is your opinion on that? I'm especially interested in what you
think about structuring packages? Do you package by layer (ie
dao,service,controller,...) or do you package by feature?
Cheers,
Christian
Daniel Wellman
Jun 14, 2009, 8:51:01 AM6/14/09
to The Java Posse
I agree with the semantics of package-by-feature. In Robert Martin's
"Agile Software Development: Principles, Patterns, and Practices"
book, he has a very big section on packaging and how it affects
coupling and reuse. I do see that many projects tend to ignore this
and package by layer (and I've been guilty of this, too).
My guess is that putting a class in a layer (or categorization) bucket
is much easier to do than putting it in a bucket by feature.
Certainly if we have to think about inheritance (e.g. I need to extend
a base Struts 2 Action class) then figuring out what package to put it
in starts to look like a similar problem ("Ah, put it in the place
with all the other things that extend Action!")
Another reason is likely to be the self-contained nature of many
projects -- if we're building a project and we aren't exporting some
portion of those classes to another team, we aren't forced to think
about API reuse or packaging. IDEs make it easy to search for classes
by name, so in that case it doesn't require much thought about where
they live.
Dan
"Agile Software Development: Principles, Patterns, and Practices"
book, he has a very big section on packaging and how it affects
coupling and reuse. I do see that many projects tend to ignore this
and package by layer (and I've been guilty of this, too).
My guess is that putting a class in a layer (or categorization) bucket
is much easier to do than putting it in a bucket by feature.
Certainly if we have to think about inheritance (e.g. I need to extend
a base Struts 2 Action class) then figuring out what package to put it
in starts to look like a similar problem ("Ah, put it in the place
with all the other things that extend Action!")
Another reason is likely to be the self-contained nature of many
projects -- if we're building a project and we aren't exporting some
portion of those classes to another team, we aren't forced to think
about API reuse or packaging. IDEs make it easy to search for classes
by name, so in that case it doesn't require much thought about where
they live.
Dan
John O'Hanley
Jun 14, 2009, 8:38:08 PM6/14/09
to The Java Posse
Hi Christian,
In addition, there is an article on javapractices.com on the same
issue:
http://www.javapractices.com/topic/TopicAction.do?Id=205
My overall feeling is that package-by-layer is a wide habit, but one
that is often worth breaking.
In addition, a problem seems to be example code. People tend to
naturally follow the style of code that is presented to them in
examples. Unfortunately, even when a framework is compatible with
package-by-feature, you will almost always see (in my experience)
framework examples that use package-by-layer.
One last comment: I find it interesting that modularity seems to be
sensitive to what I call 'the simple deletion test': if the deletion
of feature X is a single operation (for example, the deletion of a
single file or a single directory), then the implementation is very
likely modular.
- John O'Hanley
Alexey
Jun 15, 2009, 11:42:05 AM6/15/09
to The Java Posse
I think at a point, where packaging by layer starts to become a
serious handicap is where real modularity needs to come in. In most
cases, even now in Java, it doesn't have to take much effort to make
an application extensible via some sort of simple plug-in/module
architecture. If you have that, then you can go with the flow and
package by layer, and continuously factor out features into their own
module containers. I think the current package structure in the Java
language is insufficient for good, well, packaging of features, as it
doesn't easily lend itself to metadata definition and each feature may
easily contain classes that plug into different layers that need
different levels of security. So I say, we keep using packages for
layers and components/modules/plug-ins for features in conjunction
with that.
serious handicap is where real modularity needs to come in. In most
cases, even now in Java, it doesn't have to take much effort to make
an application extensible via some sort of simple plug-in/module
architecture. If you have that, then you can go with the flow and
package by layer, and continuously factor out features into their own
module containers. I think the current package structure in the Java
language is insufficient for good, well, packaging of features, as it
doesn't easily lend itself to metadata definition and each feature may
easily contain classes that plug into different layers that need
different levels of security. So I say, we keep using packages for
layers and components/modules/plug-ins for features in conjunction
with that.
Casper Bang
Jun 15, 2009, 12:59:44 PM6/15/09
to The Java Posse
As I originally commented to John, I do think he leaves out a few
desirable traits of package-by-layer. For instance, it can be
desirable to define one common backend. This allows for sharing,
validation, testing, optimization etc. in one place.
There's a price to pay for this of course, most of which revolving
around lack of modularity, vague separation-by-concerns and little
information hiding. This can make it demanding and slow for RAD/lean
teams to use package-by-layer.
Current Java is very rigid/strict at this point, a publisher and a
subscriber needs to be bound by an interface for instance - and where
to place this contract? I see dependency injection and AOP as a way to
remedy these cross-cutting concerns. At the same time I miss some of
the stuff found in C# where a name space is not a physical thing,
where there are partial classes, extension methods and method
pointers. Interestingly IDE's sometimes take a punch at this too, as
in the case of Eclipse MyLyn.
Our associative minds are wired to favor package-by-feature yet we
almost always see package-by-layer. I for one would love to hear this
"horizontal vs. vertical" aspect discussed further on the podcast. It
feels like we can do better here.
/Casper
desirable traits of package-by-layer. For instance, it can be
desirable to define one common backend. This allows for sharing,
validation, testing, optimization etc. in one place.
There's a price to pay for this of course, most of which revolving
around lack of modularity, vague separation-by-concerns and little
information hiding. This can make it demanding and slow for RAD/lean
teams to use package-by-layer.
Current Java is very rigid/strict at this point, a publisher and a
subscriber needs to be bound by an interface for instance - and where
to place this contract? I see dependency injection and AOP as a way to
remedy these cross-cutting concerns. At the same time I miss some of
the stuff found in C# where a name space is not a physical thing,
where there are partial classes, extension methods and method
pointers. Interestingly IDE's sometimes take a punch at this too, as
in the case of Eclipse MyLyn.
Our associative minds are wired to favor package-by-feature yet we
almost always see package-by-layer. I for one would love to hear this
"horizontal vs. vertical" aspect discussed further on the podcast. It
feels like we can do better here.
/Casper
Christian Beil
Jun 18, 2009, 10:06:46 AM6/18/09
to The Java Posse
I would also like the Posse to discuss this topic on the podcast. I
already posted a question (#21) on the Google Moderator for listener
feedback. You can vote on the question. Perhaps someone wants to
rewrite the question.
I find it quite hard to find out what makes a feature; it's not always
around one domain class. And where do I put (domain) classes that are
used by multiple features?
IDEs can only help to search for a class if I know its name.
already posted a question (#21) on the Google Moderator for listener
feedback. You can vote on the question. Perhaps someone wants to
rewrite the question.
I find it quite hard to find out what makes a feature; it's not always
around one domain class. And where do I put (domain) classes that are
used by multiple features?
IDEs can only help to search for a class if I know its name.
TorNorbye
Jun 18, 2009, 1:15:47 PM6/18/09
to The Java Posse
Regarding "IDEs can only help to search for a class if I know its
name.":
As of NetBeans 6.5 you can search for symbols too (Navigate > Go To
Symbol -- Ctrl-Shift-Cmd-O), not just classes - I use that sometimes
when I can't remember the class name. If I remember the method, or
field, I'm after I just use Go To Symbol to find it which takes me to
the right class.
-- Tor
name.":
As of NetBeans 6.5 you can search for symbols too (Navigate > Go To
Symbol -- Ctrl-Shift-Cmd-O), not just classes - I use that sometimes
when I can't remember the class name. If I remember the method, or
field, I'm after I just use Go To Symbol to find it which takes me to
the right class.
-- Tor
Erlend Hamnaberg
Jun 18, 2009, 2:18:31 PM6/18/09
to java...@googlegroups.com
Don't get me started on the deficiency of Netbeans. This feature is a must and has been in all others IDEs forever.
Why the hell isn't JAVA a language that needs attention in Netbeans?
Since this is written in Java, why isn't this the main language supported
Java is the LEAST developed language of them all.
You reallly need to focus on your main language, which should be Java.
I really like Netbeans. But until you get REAL editor support for JAVA, I can't use it.
Just my rant on on a Thursday.
- Erlend
Why the hell isn't JAVA a language that needs attention in Netbeans?
Since this is written in Java, why isn't this the main language supported
Java is the LEAST developed language of them all.
You reallly need to focus on your main language, which should be Java.
I really like Netbeans. But until you get REAL editor support for JAVA, I can't use it.
Just my rant on on a Thursday.
- Erlend
Ryan Waterer
Jun 18, 2009, 2:48:21 PM6/18/09
to java...@googlegroups.com
Erlend,
Netbeans has come a very long way in the last couple of years.
Since Tor has been talking about NetBeans, and the other Posse members have commented how fantastic it is, I decided to look into it again back in March. I now develop exclusively using Netbeans at home, and have started the process of switching over at work.
I suggest taking another look at it. :)
--Ryan
Netbeans has come a very long way in the last couple of years.
Since Tor has been talking about NetBeans, and the other Posse members have commented how fantastic it is, I decided to look into it again back in March. I now develop exclusively using Netbeans at home, and have started the process of switching over at work.
I suggest taking another look at it. :)
--Ryan
Bill Robertson
Jun 18, 2009, 3:20:04 PM6/18/09
to The Java Posse
On Jun 18, 2:18 pm, Erlend Hamnaberg <ngar...@gmail.com> wrote:
> I really like Netbeans. But until you get REAL editor support for JAVA, I
> can't use it.
Can't read your mind, so what do you feel is missing?> I really like Netbeans. But until you get REAL editor support for JAVA, I
> can't use it.
Casper Bang
Jun 18, 2009, 3:34:39 PM6/18/09
to The Java Posse
Yes NetBeans HAS come a very long way but it's true its not there yet.
For me, one of the few really big things missing now is line wrapping.
I see people requesting this on the bug tracker almost every single
day.
/Casper
On 18 Jun., 20:48, Ryan Waterer <aguitadel...@gmail.com> wrote:
> Erlend,
>
> Netbeans has come a very long way in the last couple of years.
>
> Since Tor has been talking about NetBeans, and the other Posse members have
> commented how fantastic it is, I decided to look into it again back in
> March. I now develop exclusively using Netbeans at home, and have started
> the process of switching over at work.
>
> I suggest taking another look at it. :)
>
> --Ryan
>
For me, one of the few really big things missing now is line wrapping.
I see people requesting this on the bug tracker almost every single
day.
/Casper
On 18 Jun., 20:48, Ryan Waterer <aguitadel...@gmail.com> wrote:
> Erlend,
>
> Netbeans has come a very long way in the last couple of years.
>
> Since Tor has been talking about NetBeans, and the other Posse members have
> commented how fantastic it is, I decided to look into it again back in
> March. I now develop exclusively using Netbeans at home, and have started
> the process of switching over at work.
>
> I suggest taking another look at it. :)
>
> --Ryan
>
> On Thu, Jun 18, 2009 at 12:18 PM, Erlend Hamnaberg <ngar...@gmail.com>wrote:
>
> > Don't get me started on the deficiency of Netbeans. This feature is a must
> > and has been in all others IDEs forever.
>
> > Why the hell isn't JAVA a language that needs attention in Netbeans?
> > Since this is written in Java, why isn't this the main language supported
> > Java is the LEAST developed language of them all.
> > You reallly need to focus on your main language, which should be Java.
>
> > I really like Netbeans. But until you get REAL editor support for JAVA, I
> > can't use it.
>
> > Just my rant on on a Thursday.
>
> > - Erlend
>
>
> > Don't get me started on the deficiency of Netbeans. This feature is a must
> > and has been in all others IDEs forever.
>
> > Why the hell isn't JAVA a language that needs attention in Netbeans?
> > Since this is written in Java, why isn't this the main language supported
> > Java is the LEAST developed language of them all.
> > You reallly need to focus on your main language, which should be Java.
>
> > I really like Netbeans. But until you get REAL editor support for JAVA, I
> > can't use it.
>
> > Just my rant on on a Thursday.
>
> > - Erlend
>
Fabrizio Giudici
Jun 18, 2009, 3:54:26 PM6/18/09
to java...@googlegroups.com
Casper Bang wrote:
> Yes NetBeans HAS come a very long way but it's true its not there yet.
> For me, one of the few really big things missing now is line wrapping.
>
> Yes NetBeans HAS come a very long way but it's true its not there yet.
> For me, one of the few really big things missing now is line wrapping.
>
Can you elaborate?
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
Fabrizio...@tidalwave.it - mobile: +39 348.150.6941
Casper Bang
Jun 18, 2009, 4:14:36 PM6/18/09
to The Java Posse
Sure, but it really would be faster to just guide you to the top 4'th
voted item on the issue tracker:
http://www.netbeans.org/issues/show_bug.cgi?id=89894
As I write somewhere among the comments, EditPlus is a good example of
the feature:
http://www.editplus.com/ss/editplus.gif
/Casper
On 18 Jun., 21:54, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:
voted item on the issue tracker:
http://www.netbeans.org/issues/show_bug.cgi?id=89894
As I write somewhere among the comments, EditPlus is a good example of
the feature:
http://www.editplus.com/ss/editplus.gif
/Casper
On 18 Jun., 21:54, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:
> Casper Bang wrote:
> > Yes NetBeans HAS come a very long way but it's true its not there yet.
> > For me, one of the few really big things missing now is line wrapping.
>
> Can you elaborate?
>
> --
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> weblogs.java.net/blog/fabriziogiudici -www.tidalwave.it/blog
> Fabrizio.Giud...@tidalwave.it - mobile: +39 348.150.6941> > Yes NetBeans HAS come a very long way but it's true its not there yet.
> > For me, one of the few really big things missing now is line wrapping.
>
> Can you elaborate?
>
> --
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> weblogs.java.net/blog/fabriziogiudici -www.tidalwave.it/blog
Fabrizio Giudici
Jun 18, 2009, 4:26:11 PM6/18/09
to java...@googlegroups.com
Casper Bang wrote:
> Sure, but it really would be faster to just guide you to the top 4'th
> voted item on the issue tracker:
> http://www.netbeans.org/issues/show_bug.cgi?id=89894
>
Thanks.> Sure, but it really would be faster to just guide you to the top 4'th
> voted item on the issue tracker:
> http://www.netbeans.org/issues/show_bug.cgi?id=89894
>
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
TorNorbye
Jun 18, 2009, 7:26:07 PM6/18/09
to The Java Posse
On Jun 18, 11:18 am, Erlend Hamnaberg <ngar...@gmail.com> wrote:
> Don't get me started on the deficiency of Netbeans. This feature is a must
> and has been in all others IDEs forever.
Maybe it's been in "all other IDEs forever", but I just fired up
> Don't get me started on the deficiency of Netbeans. This feature is a must
> and has been in all others IDEs forever.
Eclipse 3.4 and I can't find it. I'm sure it's there but I'm too
stupid to find it. Where is it?
> Why the hell isn't JAVA a language that needs attention in Netbeans?
> Since this is written in Java, why isn't this the main language supported
> Java is the LEAST developed language of them all.
> You reallly need to focus on your main language, which should be Java.
>
> I really like Netbeans. But until you get REAL editor support for JAVA, I
> can't use it.
-- Tor
TorNorbye
Jun 18, 2009, 7:45:56 PM6/18/09
to The Java Posse
Yeah, NetBeans should add soft word wrapping.
Eclipse doesn't have it either (except for a third party plugin,
currently at version 0.0.2, which doesn't work with some languages and
apparently breaks line numbering) - but people coming to NetBeans from
for example TextMate certainly miss this feature. It doesn't affect
me personally since I have a wide display and I don't want lines
longer than 120 chars (at that point I break it up) but given that
it's considered important by many users it should definitely be given
some priority. Apparently it's somewhat tricky to implement on top of
all the other magic that happens in the editor.
-- Tor
Eclipse doesn't have it either (except for a third party plugin,
currently at version 0.0.2, which doesn't work with some languages and
apparently breaks line numbering) - but people coming to NetBeans from
for example TextMate certainly miss this feature. It doesn't affect
me personally since I have a wide display and I don't want lines
longer than 120 chars (at that point I break it up) but given that
it's considered important by many users it should definitely be given
some priority. Apparently it's somewhat tricky to implement on top of
all the other magic that happens in the editor.
-- Tor
TorNorbye
Jun 18, 2009, 7:49:54 PM6/18/09
to The Java Posse
On Jun 18, 4:26 pm, TorNorbye <tor.nor...@gmail.com> wrote:
> On Jun 18, 11:18 am, Erlend Hamnaberg <ngar...@gmail.com> wrote:
>
> > Don't get me started on the deficiency of Netbeans. This feature is a must
> > and has been in all others IDEs forever.
>
> Maybe it's been in "all other IDEs forever", but I just fired up
> Eclipse 3.4 and I can't find it. I'm sure it's there but I'm too
> stupid to find it. Where is it?
(By the way I found Search > Java but I don't think that's the same
> On Jun 18, 11:18 am, Erlend Hamnaberg <ngar...@gmail.com> wrote:
>
> > Don't get me started on the deficiency of Netbeans. This feature is a must
> > and has been in all others IDEs forever.
>
> Maybe it's been in "all other IDEs forever", but I just fired up
> Eclipse 3.4 and I can't find it. I'm sure it's there but I'm too
> stupid to find it. Where is it?
feature; I'm looking for something similar to Eclipse's Open Type
dialog where you can instantly see filtered results as you're typing,
where you don't have to tell it whether you're looking for a method or
field, where you jump to the declaration (the default in that dialog
only shows references, etc.)
-- Tor
Augusto
Jun 18, 2009, 8:49:22 PM6/18/09
to The Java Posse
I like this comment from the bug report;
"This feature is necessary, for simple usability because is impossible
read a line code with thousands columns."
A line of code should never have "thousands of columns".
"This feature is necessary, for simple usability because is impossible
read a line code with thousands columns."
A line of code should never have "thousands of columns".
Peter Becker
Jun 18, 2009, 7:23:13 PM6/18/09
to java...@googlegroups.com
I feel similar. NetBeans is quite nice in many regards, but generally
lacking in terms of code hygiene. Between NetBeans not even
auto-formatting generated code and Eclipse fixing dozens of things as
"Save Actions" a lot is still to be done.
Let me elaborate. The premise is that I'm a bloody lazy guy, always
trying to care about the least amount of things possible (partly due to
bad memory ;-) ). So my standard Eclipse setup is configured to do a lot
of things on save:
* format code (on most projects only lines I changed since I don't want
messy commits)
* optimize imports (remove unnecessary, apply rules on use of .*, sort)
* add missing @Override and @Deprecated annotations
* remove trailing whitespace
* add missing braces
* add final to private members if possible
Having Eclipse do that for me on every save means I don't have to care
anymore. I like the code I read to be very neat, but I don't want to
bother writing neat code myself, with my Eclipse setup I can write:
for(Class obj: getSomething()) doSomething();
and Eclipse will turn it into:
for(Class obj: getSomething()) {
doSomething();
}
or
for(Class obj: getSomething())
{
doSomething();
}
depending on the project I'm working on (implied here is that I don't
bother thinking about a project's coding style either once my Eclipse is
all set up).
On the opposite end is NetBeans, where I have to constantly call the
code formatter and the import optimization. How can it not run at least
the generated code through a formatter?
It lacks the nice "copy imports with bits of code that use them", too.
It's good enough that I don't need to look at the import list, but it
certainly makes me think about imports more.
Otherwise I quite like NetBeans, but I really notice that it's lack of
automated code hygiene draws some of my attention away from solving real
problems to dealing with trivialities. Therefore it is currently not my
Java IDE, although I still use it for Groovy and JavaScript.
So all you NetBeans devs on this list: there is some feedback of someone
too lazy to file bug reports ;-)
Peter
lacking in terms of code hygiene. Between NetBeans not even
auto-formatting generated code and Eclipse fixing dozens of things as
"Save Actions" a lot is still to be done.
Let me elaborate. The premise is that I'm a bloody lazy guy, always
trying to care about the least amount of things possible (partly due to
bad memory ;-) ). So my standard Eclipse setup is configured to do a lot
of things on save:
* format code (on most projects only lines I changed since I don't want
messy commits)
* optimize imports (remove unnecessary, apply rules on use of .*, sort)
* add missing @Override and @Deprecated annotations
* remove trailing whitespace
* add missing braces
* add final to private members if possible
Having Eclipse do that for me on every save means I don't have to care
anymore. I like the code I read to be very neat, but I don't want to
bother writing neat code myself, with my Eclipse setup I can write:
for(Class obj: getSomething()) doSomething();
and Eclipse will turn it into:
for(Class obj: getSomething()) {
doSomething();
}
or
for(Class obj: getSomething())
{
doSomething();
}
depending on the project I'm working on (implied here is that I don't
bother thinking about a project's coding style either once my Eclipse is
all set up).
On the opposite end is NetBeans, where I have to constantly call the
code formatter and the import optimization. How can it not run at least
the generated code through a formatter?
It lacks the nice "copy imports with bits of code that use them", too.
It's good enough that I don't need to look at the import list, but it
certainly makes me think about imports more.
Otherwise I quite like NetBeans, but I really notice that it's lack of
automated code hygiene draws some of my attention away from solving real
problems to dealing with trivialities. Therefore it is currently not my
Java IDE, although I still use it for Groovy and JavaScript.
So all you NetBeans devs on this list: there is some feedback of someone
too lazy to file bug reports ;-)
Peter
Joshua Marinacci
Jun 18, 2009, 8:56:02 PM6/18/09
to java...@googlegroups.com
maybe the were entering a one-line-coding-contest? i used to type
those as a kid in the back of Nibble and Byte magazine (in apple soft
basic with a ton of semicolons :)
those as a kid in the back of Nibble and Byte magazine (in apple soft
basic with a ton of semicolons :)
Christian Beil
Jun 18, 2009, 9:08:26 PM6/18/09
to The Java Posse
Thanks Tor for pointing out Ctrl-Shift-Cmd-O, didn't know of that one.
I didn't even think of this feature. I use Eclipse most of the time,
and I don't think Eclipse has this feature. I only know of Open Type
(Ctrl-Shift-T) and Open Resource (Ctrl-Shift-R).
I didn't even think of this feature. I use Eclipse most of the time,
and I don't think Eclipse has this feature. I only know of Open Type
(Ctrl-Shift-T) and Open Resource (Ctrl-Shift-R).
TorNorbye
Jun 18, 2009, 9:08:57 PM6/18/09
to The Java Posse
I can imagine an area where it would be useful is if you have some
kind of data file, such as obfuscated JavaScript, or JSON data, and
you want to view it.
For some languages we have better ways to handle it. For both of these
scenarios (and XML etc), just hit Format (ctrl-shift-f). We will
pretty print it such that it becomes readable - much better than
simply wrapping words since for compressed JSON and compressed XML you
really want to have structure indentation as well.
But yeah, I'm not convinced it's really the top priority for the IDE.
Personally I'm really wanting more of the just-started task-oriented
work flow (Mylyn) integration. And for other developers things like
Maven and Hudson support also really help with productivity. How often
are you -editing- thousand-column files and if it's just the
occasional lookup perhaps this is something you can use another tool
for ?
(No need to try to convince me though, I don't make any decisions for
NetBeans resource allocation - I work on JavaFX now!)
-- Tor
kind of data file, such as obfuscated JavaScript, or JSON data, and
you want to view it.
For some languages we have better ways to handle it. For both of these
scenarios (and XML etc), just hit Format (ctrl-shift-f). We will
pretty print it such that it becomes readable - much better than
simply wrapping words since for compressed JSON and compressed XML you
really want to have structure indentation as well.
But yeah, I'm not convinced it's really the top priority for the IDE.
Personally I'm really wanting more of the just-started task-oriented
work flow (Mylyn) integration. And for other developers things like
Maven and Hudson support also really help with productivity. How often
are you -editing- thousand-column files and if it's just the
occasional lookup perhaps this is something you can use another tool
for ?
(No need to try to convince me though, I don't make any decisions for
NetBeans resource allocation - I work on JavaFX now!)
-- Tor
TorNorbye
Jun 18, 2009, 9:15:55 PM6/18/09
to The Java Posse
I'm always happy to share NetBeans tips :) Somebody encouraged me to
write a blog series on it a while ago, I think I might just do that
since I can't really cover my daytime work in my blog these days...
Another cool thing about our Open Type and Open Symbol implementations
is that they work cross languages and projects - so you don't have to
limit your search to Java. If you're looking for a JavaScript function
or a Groovy class it will find those too. We've put quite a bit of
work into making our language and editor infrastructure cross language
capable (so I think we have a really good story for embedded file
handling -- try reformatting files that contain HTML -and- CSS -and-
JavaScript, and ditto in PHP, ERB/RHTML files etc. And not just
formatting - try code completion, look at the navigator, go to
declaration, etc. Yep, we definitely haven't focused all our efforts
on Java support, but a lot of modern frameworks require not only good
Java support but also good support for XML, JavaScript, Ruby, etc.
etc. and prefererably not in isolation! Dick was just telling me
again how much he likes the Scala support in NetBeans :)
-- Tor
write a blog series on it a while ago, I think I might just do that
since I can't really cover my daytime work in my blog these days...
Another cool thing about our Open Type and Open Symbol implementations
is that they work cross languages and projects - so you don't have to
limit your search to Java. If you're looking for a JavaScript function
or a Groovy class it will find those too. We've put quite a bit of
work into making our language and editor infrastructure cross language
capable (so I think we have a really good story for embedded file
handling -- try reformatting files that contain HTML -and- CSS -and-
JavaScript, and ditto in PHP, ERB/RHTML files etc. And not just
formatting - try code completion, look at the navigator, go to
declaration, etc. Yep, we definitely haven't focused all our efforts
on Java support, but a lot of modern frameworks require not only good
Java support but also good support for XML, JavaScript, Ruby, etc.
etc. and prefererably not in isolation! Dick was just telling me
again how much he likes the Scala support in NetBeans :)
-- Tor
Casper Bang
Jun 19, 2009, 6:51:36 AM6/19/09
to The Java Posse
The thing is, NetBeans (and even Java itself) is no longer just used
for imperative programming where you can simply agree to conform to a
120 character line. Just staying with JEE technologies, we require
editing files full of Facelet/XML, JavaScript, SQL/JPQL annotation
etc. It's particular painful not having soft wrapping when dealing
with embedded DSL's like SQL/JPQL, since Java does not support
multiline strings making it next to impossible to copy-paste code
between tools - unless you are OK with one humongous line (one String
token).
Soft wrapping has been pushed a few times thus far, I think I remember
Jaroslav Tulac mention how hard it actually would be to do given the
existing functionality of the editor. Still lets hope we'll get it
eventually. :)
/Casper
for imperative programming where you can simply agree to conform to a
120 character line. Just staying with JEE technologies, we require
editing files full of Facelet/XML, JavaScript, SQL/JPQL annotation
etc. It's particular painful not having soft wrapping when dealing
with embedded DSL's like SQL/JPQL, since Java does not support
multiline strings making it next to impossible to copy-paste code
between tools - unless you are OK with one humongous line (one String
token).
Soft wrapping has been pushed a few times thus far, I think I remember
Jaroslav Tulac mention how hard it actually would be to do given the
existing functionality of the editor. Still lets hope we'll get it
eventually. :)
/Casper
E Winter
Jun 19, 2009, 8:43:01 AM6/19/09
to The Java Posse
I suppose it is too much of a religious war but I would love more
discussion of code style. You will have to gauge other fans but I
like to hear it hashed out. Pick a coding practice of the week (good
or bad) and riff on it for 5 minutes. I now am an anti-tab
evangelist! Coding standards are a very key thing in development
after reading Clean Code I am even keener on it.
discussion of code style. You will have to gauge other fans but I
like to hear it hashed out. Pick a coding practice of the week (good
or bad) and riff on it for 5 minutes. I now am an anti-tab
evangelist! Coding standards are a very key thing in development
after reading Clean Code I am even keener on it.
Viktor Klang
Jun 19, 2009, 8:50:59 AM6/19/09
to java...@googlegroups.com
I recently view the Google Tech Talks on Clean Code, and I hae to say htat I'm becoming more and more adverse to dereferencing things that are not either passed into the constructor of the object at hand, or into the mthod being invoked. (I.e. No calls to singletons)
When combined with Scala's excellent implicit parameters and currying, it becomes _very_ easy to deal with without losing testability.
Cheers,--
Viktor Klang
Scala Loudmouth
When combined with Scala's excellent implicit parameters and currying, it becomes _very_ easy to deal with without losing testability.
Cheers,
Viktor Klang
Scala Loudmouth
Viktor Klang
Jun 19, 2009, 8:59:09 AM6/19/09
to java...@googlegroups.com
Just as a side-note, I'm not drunk, my wireless keyboard is just low on battery...
Dan Godfrey
Jun 19, 2009, 6:14:56 AM6/19/09
to The Java Posse
One of thing missing is an Inline Variable refactoring. I use that,
along extract local variable, almost constantly while hacking code
with eclipse.
Also, the code formatter won't format to our exact code style at the
moment either, although can't remember which bit exactly it doesn't
handle.
along extract local variable, almost constantly while hacking code
with eclipse.
Also, the code formatter won't format to our exact code style at the
moment either, although can't remember which bit exactly it doesn't
handle.
Christian Beil
Jun 19, 2009, 11:03:47 AM6/19/09
to The Java Posse
To get back to the initial topic, Tor, would you discuss 'package by
layer' vs. 'package by feature' on the podcast?
layer' vs. 'package by feature' on the podcast?
Bill Robertson
Jun 19, 2009, 12:18:04 PM6/19/09
to The Java Posse
On Jun 18, 7:23 pm, Peter Becker <peter.becker...@gmail.com> wrote:
> I feel similar. NetBeans is quite nice in many regards, but generally
> lacking in terms of code hygiene. Between NetBeans not even
> auto-formatting generated code and Eclipse fixing dozens of things as
> "Save Actions" a lot is still to be done.
The little macro feature in Netbeans won't work for that?> I feel similar. NetBeans is quite nice in many regards, but generally
> lacking in terms of code hygiene. Between NetBeans not even
> auto-formatting generated code and Eclipse fixing dozens of things as
> "Save Actions" a lot is still to be done.
TorNorbye
Jun 19, 2009, 1:26:15 PM6/19/09
to The Java Posse
Save Actions. Yeah, I can see that that would be useful. I know the
hard part has already been done (there's a new action for removing
trailing whitespace for modified lines only, and they added some
infrastructure for save-time actions for that) so what's left is an
options panel for letting you choose arbitrary editor actions and then
hooking these up to the save-actions infrastructure.
Shouldn't take more than a few hours to code up. I'll take a stab at
it maybe this weekend and report back.
-- Tor
hard part has already been done (there's a new action for removing
trailing whitespace for modified lines only, and they added some
infrastructure for save-time actions for that) so what's left is an
options panel for letting you choose arbitrary editor actions and then
hooking these up to the save-actions infrastructure.
Shouldn't take more than a few hours to code up. I'll take a stab at
it maybe this weekend and report back.
-- Tor
TorNorbye
Jun 19, 2009, 1:28:29 PM6/19/09
to The Java Posse
I'll try to remember to bring it up. This is the kind of thing I
suspect the other three guys will be more passionate about than
myself.
After seeing this thread earlier in the week I went to read the
JavaWorld article and I couldn't get past the first point the author
made!
http://blogs.sun.com/tor/entry/code_advice_15_don_t
suspect the other three guys will be more passionate about than
myself.
After seeing this thread earlier in the week I went to read the
JavaWorld article and I couldn't get past the first point the author
made!
http://blogs.sun.com/tor/entry/code_advice_15_don_t
Peter Becker
Jun 19, 2009, 7:28:21 PM6/19/09
to java...@googlegroups.com
think of using it.
It would help in that I can set up a macro to call the formatter and the
organize imports, then save. It's still not what Eclipse offers, e.g.
you can't format just changed lines and I don't think NetBeans covers
all of the more advanced things such as adding finals. But I should try
such a setup, I don't really know why I didn't come up with it myself.
But even if it works: I think NetBeans should emphasize code hygiene
more. Being able to write a macro for it is better than having to write
a plugin, but it still is a conceptual burden and it won't be trivial to
spread across a project. With the Eclipse approach the Save Actions can
be configured as part of the project's configuration, then any developer
on the project will automatically use them (assuming you check in your
Eclipse config, but in an Eclipse shop that makes sense).
Of course the problem is that you can't default to anything because
whatever you chose as default >95% of the audience will disagree :-)
Peter
Peter Becker
Jun 19, 2009, 7:40:13 PM6/19/09
to java...@googlegroups.com
I had the same feeling when reading that article -- but I stopped
arguing about any flavor of hungarian notation a while ago. Unless
someone uses it on projects I work on, that is :-)
But it is good to see I was not the only one offended.
The other things I noticed is that (a) most of the stuff I don't care
about (such as where the private members go) and (b) his equals(..)
implementation is dodgy -- but I resisted going off on my little
personal crusade of hunting down all the weirdness OO caused in terms of
defining "equality", because then I would start ranting about why there
should be no Object.equals(..) to begin with :-)
Peter
arguing about any flavor of hungarian notation a while ago. Unless
someone uses it on projects I work on, that is :-)
But it is good to see I was not the only one offended.
The other things I noticed is that (a) most of the stuff I don't care
about (such as where the private members go) and (b) his equals(..)
implementation is dodgy -- but I resisted going off on my little
personal crusade of hunting down all the weirdness OO caused in terms of
defining "equality", because then I would start ranting about why there
should be no Object.equals(..) to begin with :-)
Peter
Mwanji Ezana
Jun 29, 2009, 5:15:30 AM6/29/09
to The Java Posse
On Jun 13, 1:15 pm, Christian Beil <christian.a.b...@gmail.com> wrote:
> What is your opinion on that? I'm especially interested in what you
> think about structuring packages? Do youpackageby layer (ie
> dao,service,controller,...) or do youpackagebyfeature?
I think the IDE should let you tag stuff, so you can use the view
that makes the most sense for whatever it is you are doing. So the
packages could be by feature, but you could use the Controller,
Repository, Service, etc. tag to view things in layers. Maybe the tags
could even be derived directly from EJB3 or Spring annotations.
This is kind of like the "where should private methods go?" debate: at
the end of the file, or close to where they are used? If the IDE could
give you a view that gives a good view of the method and the methods
it uses, this wouldn't be an issue.
Mwanji
> What is your opinion on that? I'm especially interested in what you
> think about structuring packages? Do youpackageby layer (ie
> dao,service,controller,...) or do youpackagebyfeature?
I think the IDE should let you tag stuff, so you can use the view
that makes the most sense for whatever it is you are doing. So the
packages could be by feature, but you could use the Controller,
Repository, Service, etc. tag to view things in layers. Maybe the tags
could even be derived directly from EJB3 or Spring annotations.
This is kind of like the "where should private methods go?" debate: at
the end of the file, or close to where they are used? If the IDE could
give you a view that gives a good view of the method and the methods
it uses, this wouldn't be an issue.
Mwanji
Christian Beil
Aug 8, 2009, 6:00:08 AM8/8/09
to The Java Posse
Here is an interesting real-life experience regarding this topic,
although C# was used :)
http://richarddingwall.name/2009/08/08/real-life-ddd-organise-code-by-responsibility-layers-not-repositories-and-services/
although C# was used :)
http://richarddingwall.name/2009/08/08/real-life-ddd-organise-code-by-responsibility-layers-not-repositories-and-services/
Rob Wilson - BabyDuke JUG
Aug 10, 2009, 8:57:46 AM8/10/09
to The Java Posse
I like the idea of organizing the packages by feature, but I wonder
where you put the common code, or code that is used in a couple of
places? For example, the domain objects might not fit exclsuvely in
one feature - like a user DAO or DTO that might be used in almost all
the features?
I guess I would struggle to decide where supporting classes should
live, are there any tips to getting this right?
Cheers,
Rob.
where you put the common code, or code that is used in a couple of
places? For example, the domain objects might not fit exclsuvely in
one feature - like a user DAO or DTO that might be used in almost all
the features?
I guess I would struggle to decide where supporting classes should
live, are there any tips to getting this right?
Cheers,
Rob.
Casper Bang
Aug 10, 2009, 9:21:30 AM8/10/09
to The Java Posse
This sort of thing is terribly difficult to discuss without concrete
examples. For shared domain stuff, you can usually still identify an
intersecting level higher up in the hierarchy no and aim to have these
as abstract as possible no? In some ways it reminds me of the hard
part of doing REST, you can't just throw your stuff into a bucket, you
really need to think hard about it and give refactoring tools their
prime time.
/Casper
On 10 Aug., 14:57, Rob Wilson - BabyDuke JUG <netp...@gmail.com>
wrote:
examples. For shared domain stuff, you can usually still identify an
intersecting level higher up in the hierarchy no and aim to have these
as abstract as possible no? In some ways it reminds me of the hard
part of doing REST, you can't just throw your stuff into a bucket, you
really need to think hard about it and give refactoring tools their
prime time.
/Casper
On 10 Aug., 14:57, Rob Wilson - BabyDuke JUG <netp...@gmail.com>
wrote:
John Nilsson
Aug 12, 2009, 6:30:37 PM8/12/09
to java...@googlegroups.com
Maybe "User" is just overloaded with meaning and should really be
split up into multiple classes (or traits if you have them) each
focused on their role in their respective package?
Or maybe "User" shouldn't be in any of them, maybe "User" is just the
mechanics to implement a specific feature which should be isolated to
its own "feature"-package implementing the services the other features
need?
BR,
John
split up into multiple classes (or traits if you have them) each
focused on their role in their respective package?
Or maybe "User" shouldn't be in any of them, maybe "User" is just the
mechanics to implement a specific feature which should be isolated to
its own "feature"-package implementing the services the other features
need?
BR,
John
Jonatan Jönsson
Sep 15, 2014, 10:39:54 AM9/15/14
to java...@googlegroups.com, net...@gmail.com
like a user DAO or DTO that might be used in almost all
the features?
I think a core/common feature would be a great place to put it. To not expose dependencies of core to other features I'd also introduce a common feature that all features can depend on, then common can be implemented by stuff in core.
Reply all
Reply to author
Forward
0 new messages