|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 74
Messages: 74
Messages: 74
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
A case against Annotations
Robin Sharp, in "Annotations: Don't Mess with Java," says that "Annotations are a major kludge on the landscape. They don't fit and we don't need them; but you just know that they'll be picked up by framework junkies and abused horribly."I’d see a case for replacing XML, and annotations. Annotations will be seen as litter on the Java landscape. One thing that strikes me about the move from XML to annotations is the shift from having a many-one relationship between code and XML to a one-one relationship between code and annotations, as well as the move from weakly-typed to more strongly-typed enforced configuration. I believe that there is a better intermediate solution that keeps a many-one relationship between code and XML as well as strongly typed configuration.
A better solution for Sun would have been to come up with an XML-like structure that could be coded into Java. This would give all the benefits of rigorous type enforcement, and the benefits of a many-one relationship between code and configuration, and the benefits of separating the configuration data out of business objects.
I would see these XML structures as being defined by something with similar semantics to XML schemas, but they would be implemented something like nested static classes containing defaults. When I look at the XML schema semantics and extended Java nested static classes, they do seem like they have similar semantics.
Extended nested static classes would provide type safety. They could be overridden by specific implementations. They could be available to introspection. Configuration would be kept in Java. I believe it would be worth exploring extending the semantics of Java nested static classes to do the job of XML configurations in a more rigorous manner than annotations provide.
Considering the recent push by some to add C++'s "friend" capability to Java, and the popular application of annotations in JEE 5, is this "too little, too late?" Has Java gone down a path it can't return from, but should?
|
|
|
Message #182285
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations are dangerous
I agree with this case against annotations. I see it as a dangerous trend that annotations are being used for things like dependency injection, web-services generation, and container-service configuration (e.g. marking methods with transactional semantics). Annotations like this simply pollute the source code and decentralizes this configuration to the point where it becomes difficult to get a system-wide big picture of such concerns.
All of these things are better done outside of the source code and centralized. The article makes a good point, however, that current XML-based configuration has no type safety. It also usually has no enforced connection to the Java component being configured. E.g. it is easy to misspell a class/method name in an XML configuration file or to not change the name after code refactor, only to discover such an error at run time.
My $0.02...
-Edgar
|
|
|
Message #182290
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Maybe just the wrong language for the job?
It seems to me that the use of annotations (including the Hibernate ones) is really a symptom of the fact that there is not a good language for describing an MVC(2) model. We have various languages, schemas, etc. for describing bits and pieces of the system, but no unified language for representing the whole.
Is such a language even possible? I suspect that the answer is 'yes' in tightly contstrianed instances, but 'no' in the more general instance - or at least 'no' in a form that is easily maintainable for the general case.
I agree with the author of the article on two points: that keeping XML and Java source in synch is a pain and that the syntax of @(....) inserted into Java looks like a kludge shoved into the code set rather than something that was well thought out an planned. Adding additional rules such as @(...)s may be over-ridden by the XML just makes support issues even more mind boggling.
Perhaps a new language which has both the concepts of Java and the annotations is needed? This could even be as simple as a preprocessor to produce the Java and XML files as required.
|
|
|
Message #182293
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations are dangerous
+1.
It's like pre-processor defintions in C++.... that made everyone go to Java.
Anotations are put there only as a version of Doclets to help EJB. So EJB is sinking the rest of Java, no child left behind style.
Go Groovy, when you hear J2EE
.V
http://roomity.com/demo.jsp
|
|
|
Message #182294
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A case against Annotations
I think like any other construct annotations can be used and misused. One case where I certainly like having them are for web services which probably were a prime motivator for their existence in .Net. Writing WSDL from scratch is pretty unpleasant.
|
|
|
Message #182295
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A case against Annotations
Annotations are a major kludge on the landscape. They don't fit and we don't need them; but you just know that they'll be picked up by framework junkies and abused horribly.
+1!
Just reminds me of the headache of mixing markup with code, or code with markup...
A better solution for Sun would have been to come up with an XML-like structure that could be coded into Java.
A long time ago... in the OpenStep platform, were constructs called P-list (property lists). They were readable, and they were a breeze to insert in source code whenever necessary...
|
|
|
Message #182297
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Move on already
Really, I am tired of this debate. Some people hate annotations, while many love them for the same reasons some people hated XDoclet and others didn't. For those that liked XDoclet, annotations are now part of the language. For those that still prefer XML, Java EE has not dropped support for it.
Really, move on people. Annotations are here to stay. If you don't want to use them, then don't.
|
|
|
Message #182300
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
...waiting
...for all the Framework and Training vendors to tell us how important it is that we have annotations.
The J2EE tools I've used were quite adept at handling the XML Meta-data, but I suppose those who refuse to pay for anything and like to code everything in UltraEdit (or gasp! vi) are loving it. All control in the hands of the coder!
Division of labor is how we've made it this far.
|
|
|
Message #182302
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
One extreme to the other...
Software needs configuration, this is true of all but the most trivial systems.
There are many options when choosing the format of this configuration. The primary candidates for Java software are probably property files, XML, RDBMSs, LDAP and now annotations.
XML has been the front runner for a few years because the industry seemed to fall in love with it. As a friend of mine placed in his slashdot sig... "XML is like violence, if it doesnt solve all your problems, just use more of it" :).
Now folks are questioning the wisdom of XML for all configuration with type safety and simple tedium being major soundbites for the anti-XML brigade.... enter annotations.
Annotations are not a new concept, I am sure some one can name a language that has had this concept since the 60s or somesuch but even in Java the popular XDoclet project has existed for some time. Now the pattern has been formalized into the language and everyone is rushing to implement all the configuration using annotations.... and surprise surprise... the 'anti-annotation' brigade is beginning to form.
The fact of the matter is, sometimes externalized XML is the right choice for configuration and sometimes annotations are. Many of us questioned the wisdom of externalizing transaction attributes in deployment descriptors, after all, when does this mythical 'deployer' ever need to tinker with transaction demarcation? Never, thats when! Annotations are great here... "Start me a transaction at this point please".
Mapping POJOs to schema on the other hand, perhaps this is a task for external configuration. It is reasonable to assume that a developer may not be intimately familier with the database schema at development time. Even in this instance, as long as the annotation data is overridable with external configuration there should be no problem.
As usual... more than one solution to the problem. Complaining how any single solution doesnt solve all the problems is a pointless endevour, even if you do word it in such a was as to sound deeply insightful.
|
|
|
Message #182303
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A case against Annotations
Meh, this is just tangible proof of the adage "you can't please all of the people all of the time". The use of xdoclet and all of it's cousins is tangible proof that some sort of standard was needed. I'd rather have it as part of the language than having a dozen random hack approaches floating around.
My thesis is simple, annotations are a great thing as long as tool vendors treat them as optional, and those that are happy with config files are free to do so. Let's not forget that it wasn't that long ago there was serious uproar about the depth of config files floating around.
- Don
|
|
|
Message #182305
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Democracy
I think annotations are a good example of Democracy at work in Java. There are a large group of people whoe (for better or worse) used and loved XDoclet. This was acknowledged and added to the spec as annotations. I personally think they have their place, and in some cases I do happly use them. I also agree, that like any new feature, they will be misused by some (or many). I think that when the dust settles annotations will have a rightful place in the Java langauge. Plus I'm sure we will learn from them and something better will be implemented in the future.
|
|
|
Message #182306
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A case against Annotations
... A long time ago... in the OpenStep platform, were constructs called P-list (property lists). They were readable, and they were a breeze to insert in source code whenever necessary...
:-) & They found their way into OSX ("plist" files)
Personally I don't like the (what seems to me as) scattered approach of Annotations either, but I guess it makes sometimes sense (e.g. for Transactions - this is much easier to add *while* coding than always going to another file for declarative notation)
Yet, both EJB & Sping have shown that there are (very) elegant solutions beyond annotations. (before I get FUD about "EJB being elegant": I just think they solved the Tx demarcation problem elegantly. No more :-)
I just hope tools will allow for refactoring all these inline annotations into external XLM files after coding. (& keeping them in sync upon choice)
This would allow -for those few cases- to use annotations *while* coding, without having a aspect-scattered, polluted code *after* coding.
Also, this would provide one central place to change all issues related to one aspect after coding, which is useful most of the times.
As long as tools would allow this (two-way?) transition, why should we care, everyone can use his own style, even within the same team. (c'mon Erich, impress us again how fast you can make Eclipse do this ;-)
This would also move the typo/... problem in XML files from runtime to compile time.
|
|
|
Message #182307
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Aspects soften Annotation problems
I'd agree with most people here that annotations enforce a 1:1 relationship between code and configuration, but it needent be that way.
For instance, with AspectJ I can introduce Annotations in a seperate file and weave this at runtime.
for instance :
aspect Configuration {
declare @methods : org.blah.Entity+.get* : @Persistent;
}
see http://eclipse.org/aspectj/doc/next/adk15notebook/annotations-declare.html for more details
|
|
|
Message #182309
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A case for Annotations
Annotations are there because they scratch an itch. Perhaps they aren't the best solution, but they are better than what was out there.
I was first driven to XDoclet by Hibernate. Hibernate was a wonderful step up from maintaining my own SQL in DAO, but man, I got tired of trying to keep the XML mappings in synch with my object classes. It's not that I'm particularly lazy, it's just that it seemed silly to try and maintain information about the same class in 2 different places.
XDoclet comes with its own set of issues, however. Most notably, waiting for XDoclet to pump out the mapping files, and ensuring that these files are bundled up into your application. The external preprocessing step makes testing in the IDE very difficult.
I've been tinkering with Hibernate3 w/ annotations lately, and it's the sanest apporach I've seen to this problem yet. I annotate the class, and it's ready to be persisted. More amazing, when using Hibernate in conjunction with HSQL running in memory, I can actually test an automatically generated clean database directly from Eclipse. This is a massive leap in productivity. Code folding in IDEs will help minimize the amount of visual clutter from annotations.
While many of you may not like Annotations, this is the easiest Java database development has ever been. Until I see a better idea in action, this is a great step forward.
|
|
|
Message #182312
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A case against Annotations
Configuration is not only case for using annotations. Annotations are great for some tasks. Wait for new version of apt tool in JSE6. It will kick ass.
For configuration on big projects we are using XML with XMLBeans. From Java I have pure Java objects with type safety which are preloaded from XML configuration files.
When administrators are not satisfied with XML configuration interface we develop GUI which is manipulating configuration.
Of course XML is stored in database and validated agains XSD schema before stored to RDBMS. Sometimes we develop additional strong checking via Schematron if administrators are too lazy to read administration guide.
Property files are too flat. RDBMS is flat, or you will need many tables if you would like to have it "correct".
With XMLBeans you can use XPath or XQuery to find right node in your configuration.
Regards
|
|
|
Message #182313
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A case against Annotations
Compared to the JUnit approach of deriving semantics from the structure of method names, I think annotations are an improvement. I agree that they can be abused, but this highlights a problem that affects most general-purpose tools - you can't disable features that you don't want to use for a particular project.
If you don't want annotations, you should probably configure a tool like 'Checkstyle' to flag any that appear in your code.
Cheers, Tony.
|
|
|
Message #182314
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Luddite, A case against Annotations
Robin's blogged rant against annotations is horribly mistaken. He wrongly blames the emergence of annotations on EJB-3 and .NET. But the original proof that Java would benefit from annotations was XDoclet. Any complaint Robin has of annotations is also an indictment of XDoclet. But Xdoclet is a proven good. Robin is a whining luddite resisting the beneficial evolution of the language specification toward an inescapable future of metaprogramming. APT kicks ass!
|
|
|
Message #182315
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations are dangerous
I agree with this case against annotations. I see it as a dangerous trend that annotations are being used for things like dependency injection, web-services generation, and container-service configuration (e.g. marking methods with transactional semantics). Annotations like this simply pollute the source code and decentralizes this configuration to the point where it becomes difficult to get a system-wide big picture of such concerns.
Decentralize?? You mean putting config datat in a type-safe manner along side your java code is decentralizing? Decentralizing is requiring 5 xml files and dealing with 'runtime' type checks and maintenance issues.
I'm not a fan of AOP or cross cutting, but annotations are specified WITH the member that is affected. From a readability and maintenance standpoint, this makes a lot more sense.
Just look at the eager adoption of EJB 3 over EJB 2.1-- EJB 2.1 didn't have annotated capabilities which left you with writing odd abstract classes and externalizing configuration information in XML. A pain to maintain and learn. Now, if you say that I can make my POJO an EJB by just writing @Stateful at the top of the class, I'm game.
http://www.onjava.com/pub/a/onjava/2005/01/19/metadata_validation.html
|
|
|
Message #182316
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations not just for configuration
The problems noted are pretty much entirely about the use of annotation for configuation. While the Hibernate, EJB3.0, and Web services annotation initiatives have put configuration in the spotlight, it's worth noting that annotations are being used in other contexts, and these don't seem particularly objectionable.
1)Annotations for creating extensions to Java for domain-specific uses. TestNG and JUnit4.0 both use annotations to make slight extensions to Java for unit testing. More small DSL-ish annotations are inevitable, and will replace/augment the sort of reflection-based implementations currently in use.
2)Annotations for extending the Java type system. Several tools now support annotations to mark fields, methods, or parameters as @NotNull, and warn you if you assign/pass/return null inappropriately. Expect to see standard annotations for design-by-contract, side-effect control, aliasing control, thread-safety issues, resource utilization requirements, and so on. Checking tools for these annotations could be either static or dynamic.
3)Design/analysis annotations. I've only seen a few stray comments on this idea, but one could certainly imagine the annotation of Java code with design-level or analysis-time information, allowing better tracing between analysis, design, code, and test.
4)Metadata/documentation annotation. Code tends to be surrounded by a cloud of related metadata, all managed by various non-standard techniques. Authorship, ownership, licensing, versioning, history, user documentation, system documentation, etc., etc. All of it's incredibly important, just not at run-time. Standardizing this stuff as annotations (possibly with the information inline, possible referenced as URLs) will enable tooling to better support access to this information. Basically annotations will be used as hooks for content-management systems, where the content being managed includes richly-linked Java source code.
|
|
|
Message #182329
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Maybe just the wrong language for the job?
It seems to me that the use of annotations (including the Hibernate ones) is really a symptom of the fact that there is not a good language for describing an MVC(2) model. That's one of the big reasons why RubyOnRails has so much fanfare. Ruby has a first-class facility for defining Domain Specific Languages such that both the DSL usage and definition are terse. Someone else here on TSS recently noted that RoR is a DSL for web MVC. Admittedly annotations are so much less than a first-class DSL definition facility.
|
|
|
Message #182332
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java not good enough?
Whenever I see a lot of semantics being interpreted out of an area which is supposed to have no meaning whatsoever (comments), I see that as an indication that the language is not good enough.
Java is a programming language with a certain syntax. If, using that syntax, you are not able to get what you want done elegantly and easily, that just means it is time to move on to a better language!
Java is a language with a managed runtime. May be someone will come up with a "real" language with all these features (IoC, AOP etc.) that compiles into bytecode. That would be a far better situation than putting all kinds of logic and meaning into your javadoc comments.
Nice (http://nice.sf.net), for example, is a brand new language that runs in the Java VM. It has generics and DBC constructs (among other things). Perhaps something like that is what we need.
|
|
|
Message #182333
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A (poor) case against Annotations
Where to start...
This is not metadata, it’s decorative data. Sure, whatever. The bottom line is that it's nice to have "Java-related" data about your code (reflection) and "Non-Java-related" data as well (Is this method a test?).
Annotations were supposed to be a replacement to XML. No, they never were. Not when we started working on them, not during the JSR 175 development and not now that annotations are being embraced left and right, and in particular, on JSR 220 (EJB 3) where annotations and XML are clearly designed to be complementary (with XML being able to override annotations at runtime).
The rule of thumb is pretty simple: whenever you are trying to describe data that pertains to a Java element (method, class, etc...), use annotations. For anything else, use XML.
Even in the most favourable(sic) light you have to admit that the implementation of annotations is a kludge. This interpretation is obviously in the eye of the beholder and anyway, the implementation seems to have received nods from most of the community. Where were you during the 18-months that it took for JSR 175 to complete? Your feedback would have been greatly appreciated back then.
Annotations are primarily a response to .NET annotations. In a small part. Annotations were created as a simple acknowledgement that they are useful, as was shown by COM on Windows 32 (way before .Net) and XDoclet on the Java platform. Formalizing them was a very obvious and unanimously praised decision. And by the way, the .Net annotations you see today are a simple formalization of the Win32 annotations, so the Windows platform followed the very same path.
A better solution for Sun would have been to come up with an XML-like structure that could be coded into Java. Now, that's a great one. Suggesting to replace annotations with XML code in Java... This has to be a joke, right?
--
Cedric
|
|
|
Message #182338
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
how are you going to feel superior?
how are you going to feel superior to your fellow developer if you don't use new things like annotations? I work with a guy that likes to use every new thing that comes out. He feels soooooo limited at work because he is forced to used jdk1.4 instead of 1.5.
|
|
|
Message #182343
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A (poor) case against Annotations
In a small part. Annotations were created as a simple acknowledgement that they are useful, as was shown by COM on Windows 32 (way before .Net) and XDoclet on the Java platform. Formalizing them was a very obvious and unanimously praised decision. And by the way, the .Net annotations you see today are a simple formalization of the Win32 annotations, so the Windows platform followed the very same path. We often hear that .NET introduced annotations but it's rare when someone remembers that even COM/Win32 had certain support for the same concepts for almost a decade...
Annotations are accepted technique and I see almost no drawbacks in it when used appropriately.
Regards,
Nikita.
GridGain Systems.
|
|
|
Message #182344
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations not just for configuration
The problems noted are pretty much entirely about the use of annotation for configuation. While the Hibernate, EJB3.0, and Web services annotation initiatives have put configuration in the spotlight, it's worth noting that annotations are being used in other contexts, and these don't seem particularly objectionable.
In addition to what you mention, I've also used them to track defects in source code. So when a fix for a given defect is applied to an element, add an annotation referencing the defect ID and a note about the fix. This allows for much richer introspection of the code for defect reporting and analysis beyond simple parsing of javadoc.
|
|
|
Message #182346
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
An xdoclet experience
My team has to maintain and fix some J2EE code that uses an older version of Xdoclet. The developers who used this in their code have left,and Xdoclet has answer version that does not support some older "annotations". Maintenace of this is a nightmare.
So annotations may seem like a smart idea at first; but we need to define the purpose and upgrade/fix path for annotated code.
|
|
|
Message #182347
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A case against Annotations
Configuration is not only case for using annotations. Annotations are great for some tasks. They are great for testing too.
The fact that a method is a "test method" has nothing to do with Java, nothing to do with the name of the method nor the package it belongs to. Hardcoding this into the method name ("the method must start with 'test'") is a hackk that finds a much better solution with annotations.
Same remark for a method that needs to be called before every test method: this piece of information has nothing to do with the name of the method.
--
Cedric
|
|
|
Message #182351
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Move on already
Really, I am tired of this debate. Some people hate annotations, while many love them for the same reasons some people hated XDoclet and others didn't. For those that liked XDoclet, annotations are now part of the language. For those that still prefer XML, Java EE has not dropped support for it.Really, move on people. Annotations are here to stay. If you don't want to use them, then don't.
Exactly, move on really..Different things for different styles..everything thing has a use and a misuse..move on..
|
|
|
Message #182352
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A case against Annotations
XML and annotations have their place. In Java, their value is overstated, because Java doesn't have a good way to express structured data. Types, yes; data, no.
You'll see annotations pressed into service with greater frequency, because they beat XML. Neither fixes the ultimate problem.
|
|
|
Message #182357
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A case against Annotations
IT does not turn around java developers and others should still be able to change a simple configuration. ...maybe with bytecode manipulation ;)
|
|
|
Message #182363
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Maybe just the wrong language for the job?
RoR is quickly becoming the Godwin's Law of Java language related discussions:
"As an online Java discussion grows longer, the probability of a comparison involving Ruby or RoR approaches 1 (i.e. certainty)."
|
|
|
Message #182368
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
fools need tools
Like I said in an earlier post, anyone actually hand-coding EJB classes rather than using tooling is making his work hard for himself.
Try Netbeans4.1 - it's free and deals with the abstraction of EJB just marvelously for the EJB2.1 spec.
vi is for reading log files, not coding, folks.
|
|
|
Message #182372
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations are dangerous
It's like pre-processor defintions in C++.... Clearly the author of this quote has either not experienced the true horrors of overuse/abuse of the C preprocessor or has not used Java annotations.
The Java 5 annotation processor will not change the source generated class file apart from attaching additional metadata. It can generate additional class files, XML, etc, but it does not change the core Java meaning.
Having dealt with the forced separation of tightly related data into separate files, seeing it get out of synch, etc, I see Java annotations as a real boon. Sure deployers should be able to override annotation-based defaults as needed -- but that's already part of the J2EE 5 design. In a broader context there are many uses of annotations which would simply be maintenance nightmares otherwise. For instance, out-of-the-box standard MBeans only obtain the bare minimum of MBeanInfo from an MBean interface (i.e. no descriptions, parameter names, operation intent, etc, are obtained). This can easily be rectified with annotations and APT, though. This allows the full MBean definition to be collocated with the Java interface definition -- providing for single-source management without having to resort to cumbersome UML driven generation of disparate artifacts (when no disparate artifacts are actually required).
|
|
|
Message #182374
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations are dangerous
While I believe annotations are wonderful for many things I do share concern with some of the other recent kitchen-sink proposals for Java.
My own personal pet peeve has to be the notion of special language coverage of XML? XML is a case for good class libraries, good APIs, etc, but not from language changes at the grammar level. This would be an unnecessary burden to learning and fully understanding the language syntax for everyone who does not use XML. I happen to use XML a lot, but I still want *nothing* to do with adding clutter to the overall language for this -- or every time some other language has a silly feature that addresses the latest marketing lemming fest.
Personally I think most of the changes in Java 5 were a very good thing *BUT* it is time to be a bit more cautious again for a while about adding more baggage to the language itself. Let the community fully digest these features and take stock of what is *really* needed rather than slocking on more crud for marketing leverage!
Annotations may actually help slow expansion of the language of itself by providing an avenue for extra metadata without expanding the language itself.
|
|
|
Message #182375
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
fools need tools
Try Netbeans4.1 - it's free and deals with the abstraction of EJB just marvelously for the EJB2.1 spec.vi is for reading log files, not coding, folks.
except for the fact that most people are deploying their ejbs to a single container, and netbeans support for that container is likely to be nill. i tried to create a simple mdb using netbeans, and also using eclipse to deploy to jboss 4.x. it was a complete waste of time. i could have had the bean put together and deployed using ant/xdoclet before learning that the leading two ide's that claim support for j2ee only have support for their own limited containers. and to migrate from container to container, you need.... xdoclet and ant.
the fact is that doing j2ee development today, now, requires the use of ant/xdoclet. once the containers are forced into a standard of recognizing the metadata about the classes to be deployed (annotations), then these technologies can be tooled around a point - n - click development.
|
|
|
Message #182376
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Dismissed! A (poor) case against Annotations
Suggesting to replace annotations with XML code in Java... This has to be a joke, right?
XML content as an annotation's value. It's already easy with Java-5 annotations. So there's no case here against annotations.
|
|
|
Message #182377
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
An xdoclet experience
The developers who used this in their code have left,and Xdoclet has answer version that does not support some older "annotations". Maintenace of this is a nightmare. Xdoclet might not have the commitment to backwards compatibility that Sun surely has with annotations.
Presumably Eclipse's References or Search can already find occurences of an annotation in a workspace. Eventually Eclipse might be enhanced to help refactor and other maintenance of annotations. How's IntelliJ at it?
|
|
|
Message #182378
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A case for Annotations
You can not prevent miss or over using of anything feature. I personally like annotations because it keeps my "application" as a whole very simple.
No body likes to "litter" their code. Annotations are certainly not litter to me. Infact they help keeping things POJO.
I completely disagree with this argument that Annotations are not good. If you don't like using annotations don't use them, that's the beauty of annotations. Annotations are about coding "freely" without worring about where the code is going to live ( J2EE container, Web services , hand held devices or washing machines, cars).
|
|
|
Message #182385
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
One extreme to the other...
....after all, when does this mythical 'deployer' ever need to tinker with transaction demarcation? Never, thats when! Annotations are great here...
Another way to say this is: all the configuration that we will "never" ever change should be in the code.
I disagree with this approach. Annotations are configuration parameters that we are including in the source code. There is no central way to manage this configuration. If you think about it, why is dependency injection so popular? Because you never know what you need to change and IOC makes it easy. Similarly you never know when you have to change configuration. Yes I have also enabled/disabled transactions on EJBs after they were written.
I believe Java is popular because it is EASY. Think about the past, why did Java tumped C that trumped Fortran that trumped assember...because it made things easier. Why was Visual Basic so popular? Why are we moving to thin clients instead of fat swin applications? Why is Ruby On Rails making so much noise? Because all of them made things easier. And after all this, we are making Java difficult to understand and code. While we are trying to simplify J2EE we are complicating J2SE. Trying to copy C# is going to harm Java.
I am already looking for alternatives. I think a new language that takes the best of Java (e.g. leave AWT/Swing and include SWT) and that will compile to Java byte code will be perfect.
|
|
|
Message #182389
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Move on already
Really, I am tired of this debate. Some people hate annotations, while many love them for the same reasons some people hated XDoclet and others didn't. For those that liked XDoclet, annotations are now part of the language. For those that still prefer XML, Java EE has not dropped support for it.Really, move on people. Annotations are here to stay. If you don't want to use them, then don't.
Unfortunately its not as easy as "If you don't want to use them, then don't". As developers we usually at some point end up maintaining other peoples code - and its easy to see that we will end up mainintaining other peoples horrendous annotations.
|
|
|
Message #182396
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations have their place
Annotations have their place precisely because they DO allow you to centralize configuration. An example - in the case of an ORM field to database column mapping, an annotation allows you to specify an ORM mapping of a database relationship where its needed rather than in some external configuration file.
The argument against annotations assumes that all configuration it this (if you can call it this) needs to be dynamic - updatable without recompiling code. Especially for applications which make heavy use of frameworks, there is often a grey area in the application which is neither application code nor configuration that you would want a system administrator to modify. Annotations as a halfway-house between Java code and XML are ideal for these scenarios and fill an obvious gap.
Whether we like EJB or not is beside the point here. Nobody can now seriously argue against the value of using frameworks in general. Annotations can make it easy to access framework services in a more controlled and easy to follow way than XML.
Yes, annotations will be misused but so has just every other language feature. Who can argue that XML configuration files have not been abused and caused a lot of pain for application developers?
|
|
|
Message #182405
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations not the answer
I am not entirely sure what the question was, but I feel convinced that annotations isn't the answer.
Pascal + inline assembler = Bad
Preprocessor + Macros + C++ = Bad
HTML + Java (in JSPs) = Bad
Inline SQL + whatever = Bad
Beer + wine = Bad
Java + Annotations = Bad
Any 2 in 1 language has proven to be bad idea.
XDoclet proving annotations was needed? Nazism proving fascism was needed?
Democratic?
Majority can make stupid descitions too (look above).
Don't remember having a vote either.
Tiger was a disapointment of Episode I/Highlander II-like proportions.
I'd like to see Mustang pretend Tiger never happened.
How do those of us who feel our language of choice has been mutilated fork Java?
This reminds of the story about the ship Wasa that sank when launched because the king had requested ever more decks.
|
|
|
Message #182406
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations not the answer
Why is it really so much better to have to edit 2 places in 1 file rather than 1 place in 2 separate files? Risk of inconsistency is reduced at best and definately not eliminated.
J2EE hell of many co-dependencies might have been a design flaw for which annotations is a cure, like amputating a hand to cure a splinter in a finger might be.
|
|
|
Message #182410
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Move on already
Really, I am tired of this debate. Some people hate annotations, while many love them for the same reasons some people hated XDoclet and others didn't. For those that liked XDoclet, annotations are now part of the language. For those that still prefer XML, Java EE has not dropped support for it.Really, move on people. Annotations are here to stay. If you don't want to use them, then don't.
I would agree with you if we where all sitting on our own island, but we are not. Some years from now we will all spent a lot of time on figuring out what is happening in existing code that is not yours and the ones who coded it are gone, good luck for then.
|
|
|
Message #182412
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations are dangerous
Prabaly you confuse configuration, metadata and code. Annotations is a good way to avoid metadata coded in method declaration (stuff like naming conventions to make framework happy). Annotations are as dangerous as any JAVA language concept if it is misused, configuration in annations is as dangerous as in method declatation(annations enhance method declatarion).
|
|
|
Message #182414
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations not the answer
I feel convinced that annotations isn't the answer.Pascal + inline assembler = BadPreprocessor + Macros + C++ = BadHTML + Java (in JSPs) = BadInline SQL + whatever = BadBeer + wine = BadJava + Annotations = BadAny 2 in 1 language has proven to be bad idea. LOL and Agree !!
Nazism proving fascism was needed? more LOL
|
|
|
Message #182415
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations (and Generics) are like dynamite ...
... in the wrong hand they can cause major harm. I like annotations (I don't like Generics that much) but as it happened in C++, as soon as the Java-Language adds more and more syntactic sugar a lot of developers will explore these territories to produce syntactically spectacular, but probably unmaintainable code.
For me, especially Generics add a whole new layer of complexity on Java. My brain must cope now with these brackets that weren't previously used in Java except for arithmetics.
It's not the code I actually write (I mostly understand my own code :-) but the code that is written by others and which you have to maintain.
|
|
|
Message #182427
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations have their place
...Who can argue that XML configuration files have not been abused and caused a lot of pain for application developers?
Even though a knife can be abused it is not okay to hand over guns to everybody. A knife is lightweight, is easy to understand, simple to use and comes in handy for tons of tasks. A gun is heavy, you need training/practice to handle and use it, is lot more dangerous than a knife and performs only one specific function that we are better off living without.
XML is not complex, it is easy to understand and comes in handy for tons of tasks. Annotations make code difficult to read/understand, there is a learning curve involved to understand annotations, perform a very specific function.
Essentially my argument is that the complexity of annotations/generics does not justify the returns.
|
|
|
Message #182435
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Waiting no more, I create my own solution
Not talking about configuration in general and getting into the argument of annotations, but I did want a more natual way of configuring, particularly the Spring framework. Thus I have created Jacn to meed my need.
Take a look at this code snippet, which's a fully configured Spring application without XML.
public class SimpleFlatJacnApp {
public static void main(String[] args) throws Exception {
ApplicationContext ctx = new JacnApplicationContext(Jacn_foo.class);
Foo foo = (Foo) ctx.getBean("foo");
System.out.println(foo.getBar().getMsg());
}
// the inner configuration file !
static class Jacn_foo extends AbstractJacnConfigFile{
static Foo foo;
static Bar bar;
public void wire() throws Exception {
bar = new Bar("hello");
foo.setBar(bar);
}
}
static class Foo {
Bar bar;
public Bar getBar() {return bar;}
public void setBar(Bar bar) {this.bar = bar;}
}
static class Bar {
String msg;
private Bar(String msg) {this.msg = msg;}
public String getMsg() {return msg;}
}
}
The DI configuration is in the inner class Jacn_foo (of course it should go to a standalone class for any none-trivial DI description. ), which looks like Java (the compiler thinks so) but not really used as Java. It describes how a Bar instance (a singleton here) should be constructed and how it will be injected into a singleton Foo instance.
I have a web application with ~180 managed objects configured this way, strongly typed and totally refactorable. I have made myself happy.
Bing
http://jacn.sf.net/
|
|
|
Message #182441
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
One extreme to the other...
I believe Java is popular because it is EASY. Think about the past, why did Java tumped C that trumped Fortran that trumped assember...because it made things easier. Interestingly, you didn't say that C++ trumped C... Could it be because it invalidates your point that languages become easier over time? :-)
Languages don't have to be easier to become mainstream, and if I was asked to name one feature that has complicated the language recently, I would certainly pick Generics over Annotations, which are just declarative syntactic sugar.
--
Cedric
|
|
|
Message #182453
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations are dangerous
+1.It's like pre-processor defintions in C++.... that made everyone go to Java.Anotations are put there only as a version of Doclets to help EJB. So EJB is sinking the rest of Java, no child left behind style. Go Groovy, when you hear J2EE.Vhttp://roomity.com/demo.jsp
Thanks Vic. I tried the demo (not knowing what it was) and basically all it did was mess the settings of the graphics card enough to force me to reboot without any possibility to save my current work.
Hope you make a buck on your new virus.
|
|
|
Message #182468
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations not the answer
I am not entirely sure what the question was, but I feel convinced that annotations isn't the answer.Pascal + inline assembler = BadPreprocessor + Macros + C++ = BadHTML + Java (in JSPs) = BadInline SQL + whatever = BadBeer + wine = BadJava + Annotations = BadAny 2 in 1 language has proven to be bad idea. Define "bad idea"...
All the technologies you listed above might not be optimal, but they have obviously been very successful in the market place, and they have spurned further efforts to refine them. They worked back then, and their successors work even better now. I don't see what's not to like.
As for multiple languages, it's a reality of today's programming. Ten years ago, you could get entire projects done with one single language, but it's no longer the case now. It's just the manifestation of the fact that the problems we solve have become more complex, and they require more complex technologies to address them.
--
Cedric
|
|
|
Message #182492
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations have their place
If you'd rather write an entire WSDL than add "@WebService" to a class, be my guest.
And while you're still trying define your complex data types in XML, I'll deploy my web service and have time left over to master generics.
|
|
|
Message #182493
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Move on already
Unfortunately its not as easy as "If you don't want to use them, then don't". As developers we usually at some point end up maintaining other peoples code - and its easy to see that we will end up mainintaining other peoples horrendous annotations.
Well that's true in general of any and all features not just annotations. Many of them have good uses and can be misused. It's upto each team and organization to determine how and what and then whoever does the maintanence ends up following the agreed upon practices..
|
|
|
Message #182495
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Move on already
I would agree with you if we where all sitting on our own island, but we are not. Some years from now we will all spent a lot of time on figuring out what is happening in existing code that is not yours and the ones who coded it are gone, good luck for then.
Figuring out what is happening in existing code requires a lot of patience to deal with a lot of bad practices that might have been the norm for the team and/or developer who wrote a piece of code..and then a lot times there are no blacks and whites but subjective shades of gray..
|
|
|
Message #182521
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
One extreme to the other...
I believe Java is popular because it is EASY. Think about the past, why did Java tumped C that trumped Fortran that trumped assember...because it made things easier. Interestingly, you didn't say that C++ trumped C... Could it be because it invalidates your point that languages become easier over time? :-)Languages don't have to be easier to become mainstream, and if I was asked to name one feature that has complicated the language recently, I would certainly pick Generics over Annotations, which are just declarative syntactic sugar.-- Cedric
Good point Cedric. C++ became popular because OOP became a must. The benefits of OOP outweighed the complexity of the language. In reality, it is the rewards/cost ratio that determines the success. Mostly it aligns with simplicity by decreasing the cost. Once in a while (like C++) the increase in rewards outpace the increase in cost.
In any case, you seem to agree with my comment in general. That is what is important.
|
|
|
Message #182559
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations are interfaces...
Annotations are interfaces...
...and should be used as such. One place I am already using them is for event handling and they are a GREAT.
|
|
|
Message #182574
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations not the answer
Define "bad idea"...
All the technologies you listed above might not be optimal, but they have obviously been very successful in the market place, and they have spurned further efforts to refine them. They worked back then, and their successors work even better now. I don't see what's not to like.
As for multiple languages, it's a reality of today's programming. Ten years ago, you could get entire projects done with one single language, but it's no longer the case now. It's just the manifestation of the fact that the problems we solve have become more complex, and they require more complex technologies to address them.--
Different layers of abstraction or entirely different ways of thinking in one source file is bad because it makes true asm/pascal/C++/Java-zen state of mind impossible.
Mixed syntax is a defacto violation of "separation of concerns" sorta.
|
|
|
Message #182675
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations not the answer
Different layers of abstraction or entirely different ways of thinking in one source file is bad because it makes true asm/pascal/C++/Java-zen state of mind impossible. 1) Not sure what these zens are
2) Not sure why they're impossible
3) Not sure that the fact they're impossible is a bad thing :-)
Mixed syntax is a defacto violation of "separation of concerns" sorta. You might want to double check the meaning of "de facto", I don't think it means what you think it means :-)
Here is a defacto... er... fact: Programmers have been using multiple languages and multiple paradigms in the same source file for at least a decade now:
- JSP + HTML
- HTML + CSS
- J2EE + XML
- HTML + JavaScript
- and of course, you can find similar examples in the Win32 world as well (C++ + resource files, etc...)
--
Cedric
|
|
|
Message #182740
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java is the best language for configuration, not XML !!!
Why not stick to the Java language when dealing with configuration ???
Why instead of struts-config.xml or xwork.xml we cannot have a struts-config.java or a xwork.java ???
Two understand this new idea, check this project:
http://mentawai.lohis.com.br/
|
|
|
Message #182749
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java is the best language for configuration, not XML !!!
Why not stick to the Java language when dealing with configuration ???Why instead of struts-config.xml or xwork.xml we cannot have a struts-config.java or a xwork.java ??? I think it's a very bad idea.
If I change a runtime parameter, I need to rebuild this file, which means having my classpath and compiler set up correctly (ant, maven or whatever)?
Maybe XML is not the best format for this, but whatever format you decide to use, it should definitely be editable easily and be picked up right away by the framework without any additional compiling or processing phase.
--
Cedric
|
|
|
Message #182750
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java is the best language for configuration, not XML !!!
Why not stick to the Java language when dealing with configuration ???Why instead of struts-config.xml or xwork.xml we cannot have a struts-config.java or a xwork.java ??? Sorry I posted too fast, I had one more comment to make:
Saying that configuration in your framework is done with a .java is incorrect: it is actually done with a .class.
Do you really think .class makes more sense that .xml?
--
Cedric
|
|
|
Message #182758
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations not the answer
All the technologies you listed above might not be optimal, but they have obviously been very successful in the market place, and they have spurned further efforts to refine them.
You could say the same for Perl ..
;-)
Peace,
Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java
|
|
|
Message #182769
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java is the best language for configuration, not XML !!!
Why not stick to the Java language when dealing with configuration ???Why instead of struts-config.xml or xwork.xml we cannot have a struts-config.java or a xwork.java ??? I think it's a very bad idea.If I change a runtime parameter, I need to rebuild this file, which means having my classpath and compiler set up correctly (ant, maven or whatever)?Maybe XML is not the best format for this, but whatever format you decide to use, it should definitely be editable easily and be picked up right away by the framework without any additional compiling or processing phase.-- Cedric
BeanShell
|
|
|
Message #182775
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java is the best language for configuration, not XML !!!
Why not stick to the Java language when dealing with configuration ???Why instead of struts-config.xml or xwork.xml we cannot have a struts-config.java or a xwork.java ??? Sorry I posted too fast, I had one more comment to make:Saying that configuration in your framework is done with a .java is incorrect: it is actually done with a .class.Do you really think .class makes more sense that .xml?-- Cedric
Compiling is a good thing and not a bad thing like you suggest. Keep in mind that you are only compiling the configuration file, not the entire application. You application is separated from the configuration file.
How much time do you lose by compiling a single .java file ??? Very little and you have a chance to catch stupid mistakes at compile-time. How about XML ???
XML may be better for RAD applications, like JDeveloper. BeanShell is an option, too.
|
|
|
Message #182779
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java is the best language for configuration, not XML !!!
You application is separated from the configuration file. No it's not, because your application need to re-classload the configuration file.
Definitely not as simple as reparsing a simple file on your file system.
How much time do you lose by compiling a single .java file You are missing the point. It's not about the time it takes to recompile the file but about the inconvenience of it: you need to have your classpath set up and basically, invoke a part of your build infrastructure just to incorporate a change in configuration.
--
Cedric
|
|
|
Message #182785
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The real danger: Version dependence
The big problem with using annotations is that you start depending on J2SE 1.5/5.0, which for some dev houses can be a leap. This also is an issue with app-server vendors and tool vendors which "certify" their products against a version (like 1.3 or 1.4) and which will often be "behind the curve" in 1.5 support. Technologies that exist as libraries (like XDoclet) independent on Java version are easier to deploy in existing installations.
Examples of "new" Java technologies that were implemented as libraries and hence could be "back-ported" to, or already existed as separate libraries for, older JRE version include Swing, the Collections framework and XML/XSL/DOM.
So e.g. EJB 3 and the newest Hibernate requiring annotations will inevitably put brakes on their adoptation in the industry because they come with that extra baggage. Annotations as such are not dangerous (though working around the one-to-one relations can be a pain, as well as having to rebuild instead of reconfigure and restart), but they represent an uphill climb compared to "external" technologies using libraries.
|
|
|
Message #182786
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations not the answer
You might want to double check the meaning of "de facto", I don't think it means what you think it means :-)
Right. English is not my first language, which might be a wierd argument for a latin phrase. I apologize for using a phrase I am not entirely sure what means. I thought it meant something along the lines of "per default".
Here is a defacto... er... fact: Programmers have been using multiple languages and multiple paradigms in the same source file for at least a decade now:
- JSP + HTML
- HTML + CSS
- J2EE + XML
- HTML + JavaScript
- and of course, you can find similar examples in the Win32 world as well (C++ + resource files, etc...)
My point was that in most (if not all) cases it has proven to be a bad idea.
Java + HTML in JSP was replaced by taglibs + HTML which is more consistent and doesn't require 2 completely different ways of thinking.
HTML + CSS can be written as separate files if i am not mistaking (seperation is good).
J2EE + XML, not entirely sure what you mean by this. I thought discussion was more about whether it is a good idea to have a single language that does various completely different things. Not whether you can use 2 technologies together but separate.
HTML + JavaScript. In my organization there has been a tendency of separating HTML and JavaScript. I assume the HTML people have had good reasons for doing this.
I sorta learned to live with javadoc, probably because I never used it much. First thing i did when assuming responsibility for a bunch of source files was remove all comments and javadoc. Comments often make code too verbose and doesn't really explain anything.
I think compiling one source file with 2 different compilers is inherently a bad thing, it is a first step down a slippery slope. If 2 compilers for one source file is OK, why not 3 or 4 or 10? Besides metadata we could include ressources, SQL etc. /shiver
|
|
|
Message #182854
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java is the best language for configuration, not XML !!!
You application is separated from the configuration file. No it's not, because your application need to re-classload the configuration file.Definitely not as simple as reparsing a simple file on your file system.How much time do you lose by compiling a single .java file You are missing the point. It's not about the time it takes to recompile the file but about the inconvenience of it: you need to have your classpath set up and basically, invoke a part of your build infrastructure just to incorporate a change in configuration.-- Cedric
In most MVC web frameworks I have seen, YOU MUST RESTART YOUR APPLICATION WHEN YOU CHANGE YOUR XML FILE. So we are even !
Sure, you can implement something crazy to check the timestamp of your XML file and reload it when it changes. YOU CAN DO THE SAME THING WITH A .CLASS FILE. I agree it is more difficult, but once you have done it, it is done. The framework may provide this, so you don't have to do anything.
I don't think this is inconvenient.
javac ApplicationManager.java
or
ant config-compile
That's it. What is the inconvinience ???
;-)
|
|
|
Message #182855
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java is the best language for configuration, not XML !!!
Sure, you can implement something crazy to check the timestamp of your XML file and reload it when it changes. YOU CAN DO THE SAME THING WITH A .CLASS FILE. I agree it is more difficult, but once you have done it, it is done. The framework may provide this, so you don't have to do anything.
You are right. This may be hard stuff, because classes are cached by classloader. Howerver this is not impossible.
Another option is two dynamically change the ApplicationManager instance, instead of changing the class. However the .java file will not reflect these changes.
I admitt I have to think better about it, because Java classloaders are a pain.
However I have a question for you:
Can Struts, Spring and WW detect that the XML file has changed and reload it WITHOUT RESTARTING THE APPLICATION CONTEXT ???????????? I would bet no, but I may be wrong...
|
|
|
Message #183059
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java is the best language for configuration, not XML !!!
I'm not sure at all that system administrators would much enjoy managing .java and .class files for the multiple environments where the applications are running in.
As a developer I do prefer xml files, but some of the sysadmin's i have been working with do definitively prefer properties files.
In the end it are the sysadmins who will be the ones spending their time configuring the files, so it's quite important they are comfortable with.
As for the restarting or not, it's the same problem for java, xml or properties files, it's a framework issue.
|
|
|
Message #183157
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I think they do have a place
Annotations have a place. I agree with those who say it's dangerous to use annotations in a large application. However, there are a lot of smaller applications where a single developer or a handful of people are just trying to get something to work and they don't need the added complexity of another file.
Java and J2EE suffer, in my opinion, from complexity and need stuff like annotations to make the technology more welcoming. I am a professional J2EE developer, but almost nobody I know outside work wants to use J2EE for their projects. When I try to explain what they need, they run away from J2EE and start using things like PHP.
Ultimately it is the responsibility of the architect to use the features of the technology wisely and appropriately. We all know that it's a bad idea to embed, say, JDBC code inside a JSP page, but the capability to do it is still there, and we trust decent developers to do the right thing.
Frank
|
|
|
Message #183467
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java good enough?
The fact that some developers want features to more easily do certain things is not by itself indicative of language merit.
Are they even trying to do the right things? Many developers these days are ignoring the hard learned lessons of decades past (loosely coupled designs, well decomposed, understandable code, etc) in favor of code candy to do 'cool' things.
Another post had mentioned Stroustrop's Design and Evolution of C++, which remains one of my favorite books, because much of the thought that guided the initial design of C++ was in fact quite language independent, particuarly the reluctance to encumber the language with features whose benefit is narrowly focused to a limited problem set.
After 40 years of programming in everything from FORTRAN to Java, I've seen many examples of people not learning from history and having to repeat it, usually the hard way. I've also observed that when developers want a language feature to support a narrow use, they often need to think deeper about what they are trying to do and find a better design.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
