Is there a standard representation for typed java collections in UML2? I am working on a class diagram and would like to avoid Java syntax, when using something like Map as type for a class attribute.
- foo : Map<Integer, String>
UML2 has parameterized classes, and the syntax is in fact pretty much the same as Java's - both Java and the UML spec were inspired by the C++ syntax here.
I'm against using too much design documents to program. Documents are only for communicating ideas, IMHO.
So if you need Java Types for your UML chances are:
you are reverse engineering: then Java Syntax will be fine
you are trying to program trhough UML: don't do it. Program in Java. Use UML only for object relation and collaboration
if the types are primitive: it's likely you don't need to express internal data structures in UML. You only need to express what's the responsibility of the class.
if the types are objects: ok, maybe it's the point... I'm not sure, but try to use the minimum...
Related
UML classdiagrams are a standard graphical notation to describe classes and their relationships.
Is there a standard textual notation (DSL) to describe the same? Don't say XMI or EMF;-)
I think you could do that with Corba IDL and use Interfaces for classes, but this is somehow too much on the Corba side. You could use Java Interfaces, but this is too Java.
Background of my question is writing generators. I think it is easier to write a generator based on the syntax tree of a DSL than to parse a graphical notation. A graphical notation first has to be translated into a syntax tree (that would be the same you'd get from the corresponding DSL). I think translating a graphical notation into the syntax tree is harder than to translate a DSL (where you can use ANTLR).
You've got the answer already, but I'd like to clarify. There is a standard notation, it's called HUTN, and nobody uses it.
Check this complete list of textual notations to describe UML models. Btw, the reasons to create one of these tools (in particular TextUML) can be find here.
It is no coincidence that UML separates abstract and concrete syntax.
Tying up code generation to a user-facing notation is a bad idea. Tools (code generators) and people (modelers) have totally distinct needs, so no single syntax can serve both audiences well. Not to mention you lose the ability of applying the same code generator to models created using different notations.
TextUML is a concrete syntax tailored to modelers. XMI is a much better notation for tools, and the UML2 object model makes it very easy to handle.
Rafael
http://abstratt.com/blog
No standard notation to my knowledge but a good summary of options here.
hth.
Hi the following post says there is "built in dependency injection" in scala
"As a Scala and Java developer, I am not even slightly tempted to
replace Scala as my main language for my next project with Java 8. If
I'm forced to write Java, it might better be Java 8, but if I have a
choice, there are so many things (as the OP correctly states) that
make Scala compelling for me beyond Lambdas that just adding that
feature to Java doesn't really mean anything to me. Ruby has Lambdas,
so does Python and JavaScript, Dart and I'm sure any other modern
language. I like Scala because of so many other things other than
lambdas that a single comment is not enough.
But to name a few (some were referenced by the OP)
Everything is an expression, For
comprehensions (especially with multiple futures, resolving the
callback triangle of death in a beautiful syntax IMHO), Implicit
conversions, Case classes, Pattern Matching, Tuples, The fact that
everything has equals and hashcode already correctly implemented (so I
can put a tuple, or even an Array as a key in a map), string
interpolation, multiline string, default parameters, named parameters,
built in dependency injection, most complex yet most powerful type
system in any language I know of, type inference (not as good as
Haskell, but better than the non existent in Java). The fact I always
get the right type returned from a set of "monadic" actions thanks to
infamous things like CanBuildFrom (which are pure genius). Let's not
forget pass by name arguments and the ability to construct a DSL.
Extractors (via pattern matching). And many more.
I think Scala is
here to stay, at least for Scala developers, I am 100% sure you will
not find a single Scala developer that will say: "Java 8 got lambdas?
great, goodbye scala forever!". Only reason I can think of is compile
time and binary compatibility. If we ignore those two, all I can say
is that this just proves how Scala is in the right direction (since
Java 8 lambdas and default interface methods and steams are so clearly
influenced)
I do wish however that Scala will improve Java 8
interoperability, e.g. support functional interfaces the same way. and
add new implicit conversions to Java 8 collections as well as take
advantage to improvements in the JVM.
I will replace Scala as soon as
I find a language that gives me what Scala does and does it better. So
far I didn't find such a language (examined Haskell, Clojure, Go,
Kotlin, Ceylon, Dart, TypeScript, Rust, Julia, D and Nimrod, Ruby
Python, JavaScript and C#, some of them were very promising but since
I need a JVM language, and preferably a statically typed one, it
narrowed down the choices pretty quickly)
Java 8 is by far not even
close, sorry. Great improvement, I'm very happy for Java developers
that will get "permission" to use it (might be easier to adopt than
Scala in an enterprise) but this is not a reason for a Scala shop to
consider moving back to Java." [1]
what is exactly the built in dependency injection in scala?
It's not a discrete language feature. I think the author was referring to the fact that Scala's feature set is flexible enough to support a number of techniques that could be said to accomplish DI:
the cake pattern, building on the trait system
the Reader monad, building on higher-kinded types
DI through currying, building on functional techniques
using implicit class parameters, building on Scala's concept of implicits
in my own project, we accomplish DI by requiring function values in the class constructor explicitly
This diversity is rather emblematic of Scala. The language was designed to implement a number of very powerful concepts, mostly orthogonally, resulting in multiple valid ways to solve many problems. The challenge as a Scala programmer is to understand this breadth and then make an intelligent choice for your project. A lot of times, that choice depends on what paradigms are being used internally to implement your components.
I'm currently working with Java to write a program that does an EAI between two applications. One application comes with HL7, which I parse with HAPI. So I get a Java object structure. I want to transform this structure to my own structure that I want to use to generate XML files with JAXB after doing some other work.
In my opinion my current solution is not very nice, because the source code gets very complex:
public NaturalPerson convertPID(PID pid) {
NaturalPerson person = new NaturalPerson();
NameNaturalPerson personsname = new NameNaturalPerson();
name.setFamilyName(pid.getPatientName().getFamilyName().getValue());
...
}
Which language is an appropiate Language to do such type mappings? (http://en.wikipedia.org/wiki/List_of_JVM_languages)
I think Java is not the best language for doing that. I don't have much time for learning, so I need a language that is easy to learn and which has a low begin-of-learning-peek. I already have some experience in the functional languages Haskell and F#. First I thought Groovy would be a good language, but then I found other opinions that suggest Scala.
Which language would you suggest for doing such type mappings?
Did you look at Dozer? It is a Java library that recursively copies data from one Java object to another. There are several ways to configure the mapping:
XML
Java API providing a DSL
Java annotations
Data in forms of Maps and Vectors handling are superbly handled on the JVM using Clojure
See all the core functions available and this SO Question on which tutorials are good to learn Clojure.
Coming from a C and C++ background, I found judicious use of typedef to be incredibly helpful. Do you know of a way to achieve similar functionality in Java, whether that be a Java mechanism, pattern, or some other effective way you have used?
Java has primitive types, objects and arrays and that's it. No typedefs.
If this is what you mean, you can simply extend the class you would like to typedef, e.g.:
public class MyMap extends HashMap<String, String> {}
There is no typedef in java as of 1.6, what you can do is make a wrapper class for what you want since you can't subclass final classes (Integer, Double, etc)
As others have mentioned before,
There is no typedef mechanism in Java.
I also do not support "fake classes" in general, but there should not be a general strict rule of thumb here:
If your code for example uses over and over and over a "generic based type" for example:
Map<String, List<Integer>>
You should definitely consider having a subclass for that purpose.
Another approach one can consider, is for example to have in your code a deceleration like:
//#Alias Map<String, List<Integer>> NameToNumbers;
And then use in your code NameToNumbers and have a pre compiler task (ANT/Gradle/Maven) to process and generate relevant java code.
I know that to some of the readers of this answer this might sound strange, but this is how many frameworks implemented "annotations" prior to JDK 5, this is what project lombok is doing and other frameworks.
Really, the only use of typedef that carries over to Javaland is aliasing- that is, giving the same class multiple names. That is, you've got a class "A" and you want "B" to refer to the same thing. In C++, you'd be doing "typedef B A;"
Unfortunately, they just don't support it. However, if you control all the types involved you CAN pull a nasty hack at the library level- you either extend B from A or have B implement A.
Perhaps this could be another possible replace :
#Data
public class MyMap {
#Delegate //lombok
private HashMap<String, String> value;
}
As noted in other answers, you should avoid the pseudo-typedef antipattern. However, typedefs are still useful even if that is not the way to achieve them. You want to distinguish between different abstract types that have the same Java representation. You don't want to mix up strings that are passwords with those that are street addresses, or integers that represent an offset with those with those that represent an absolute value.
The Checker Framework enables you to define a typedef in a backward-compatible way. I works even for primitive classes such as int and final classes such as String. It has no run-time overhead and does not break equality tests.
Section Type aliases and typedefs in the Checker Framework manual describes several ways to create typedefs, depending on your needs.
Kotlin supports type aliases https://kotlinlang.org/docs/reference/type-aliases.html. You can rename types and function types.
In some cases, a binding annotation may be just what you're looking for:
https://github.com/google/guice/wiki/BindingAnnotations
Or if you don't want to depend on Guice, just a regular annotation might do.
You could use an Enum, although that's semantically a bit different than a typedef in that it only allows a restricted set of values. Another possible solution is a named wrapper class, e.g.
public class Apple {
public Apple(Integer i){this.i=i; }
}
but that seems way more clunky, especially given that it's not clear from the code that the class has no other function than as an alias.
Typedef allows items to be implicitly assigned to types they are not. Some people try to get around this with extensions; read here at IBM for an explanation of why this is a bad idea.
Edit: While strong type inference is a useful thing, I don't think (and hope we won't) see typedef rearing it's ugly head in managed languages (ever?).
Edit 2: In C#, you can use a using statement like this at the top of a source file. It's used so you don't have to do the second item shown. The only time you see the name change is when a scope introduces a name collision between two types. The renaming is limited to one file, outside of which every variable/parameter type which used it is known by its full name.
using Path = System.IO.Path;
using System.IO;
There is no need for typedef in Java. Everything is an Object except for the primitives. There are no pointers, only references. The scenarios where you normally would use typedefs are instances in which you create objects instead.
Besides the dynamic nature of Python (and the syntax), what are some of the major features of the Python language that Java doesn't have, and vice versa?
List comprehensions. I often find myself filtering/mapping lists, and being able to say [line.replace("spam","eggs") for line in open("somefile.txt") if line.startswith("nee")] is really nice.
Functions are first class objects. They can be passed as parameters to other functions, defined inside other function, and have lexical scope. This makes it really easy to say things like people.sort(key=lambda p: p.age) and thus sort a bunch of people on their age without having to define a custom comparator class or something equally verbose.
Everything is an object. Java has basic types which aren't objects, which is why many classes in the standard library define 9 different versions of functions (for boolean, byte, char, double, float, int, long, Object, short). Array.sort is a good example. Autoboxing helps, although it makes things awkward when something turns out to be null.
Properties. Python lets you create classes with read-only fields, lazily-generated fields, as well as fields which are checked upon assignment to make sure they're never 0 or null or whatever you want to guard against, etc.'
Default and keyword arguments. In Java if you want a constructor that can take up to 5 optional arguments, you must define 6 different versions of that constructor. And there's no way at all to say Student(name="Eli", age=25)
Functions can only return 1 thing. In Python you have tuple assignment, so you can say spam, eggs = nee() but in Java you'd need to either resort to mutable out parameters or have a custom class with 2 fields and then have two additional lines of code to extract those fields.
Built-in syntax for lists and dictionaries.
Operator Overloading.
Generally better designed libraries. For example, to parse an XML document in Java, you say
Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse("test.xml");
and in Python you say
doc = parse("test.xml")
Anyway, I could go on and on with further examples, but Python is just overall a much more flexible and expressive language. It's also dynamically typed, which I really like, but which comes with some disadvantages.
Java has much better performance than Python and has way better tool support. Sometimes those things matter a lot and Java is the better language than Python for a task; I continue to use Java for some new projects despite liking Python a lot more. But as a language I think Python is superior for most things I find myself needing to accomplish.
I think this pair of articles by Philip J. Eby does a great job discussing the differences between the two languages (mostly about philosophy/mentality rather than specific language features).
Python is Not Java
Java is Not Python, either
One key difference in Python is significant whitespace. This puts a lot of people off - me too for a long time - but once you get going it seems natural and makes much more sense than ;s everywhere.
From a personal perspective, Python has the following benefits over Java:
No Checked Exceptions
Optional Arguments
Much less boilerplate and less verbose generally
Other than those, this page on the Python Wiki is a good place to look with lots of links to interesting articles.
With Jython you can have both. It's only at Python 2.2, but still very useful if you need an embedded interpreter that has access to the Java runtime.
Apart from what Eli Courtwright said:
I find iterators in Python more concise. You can use for i in something, and it works with pretty much everything. Yeah, Java has gotten better since 1.5, but for example you can iterate through a string in python with this same construct.
Introspection: In python you can get at runtime information about an object or a module about its symbols, methods, or even its docstrings. You can also instantiate them dynamically. Java has some of this, but usually in Java it takes half a page of code to get an instance of a class, whereas in Python it is about 3 lines. And as far as I know the docstrings thing is not available in Java