Java Annotations – Why Use @Native Annotations?

javajava8

link : http://download.java.net/jdk8/docs/api/java/lang/annotation/Native.html

In Java 8, there will be @Native annotations.

Indicates that a field defining a constant value may be referenced from native code. The annotation may be used as a hint by tools that generate native header files to determine whether a header file is required, and if so, what declarations it should contain.

Problem is: What for?
Do you have any idea on which problematics would be efficiently solved by this feature?

Best Answer

Imagine a header which defines constants to be used in messaging. One party of the conversation might be developed in C++, and they'd like to #include a header. Now maintaining two similar but separate files is a risk; deriving the C++ header from @Native constants is safer.

Possible Uses

Fast Prototyping

You could do this with Groovy or others, so that's not a very strong point, but as CRaSH gives you code-level access to the JVM and the processes it runs, it may come in handy to just keep a JVM running and experiment with small code snippets (for instance, using it as a REPL to implement solutions to StackOverflow questions).

The JCR extension would seem potentially useful to supplement this, by giving you shell access to remote repositories, and contains a notion of workspace to separate projects.

Interacting with a Running Process

I could see this being an interesting use case. I don't know of many good process inspection command-line tools for JVM processes, apart from the JDK-packaged ones. CRaSH might help in interacting with them in novel ways.

For instance, you can use the Attach Mode to attach to a running JVM, and then use the thread command to ls, dump or interrupt threads.

You could also write some additional control commands for non-programmers to use CRaSH to perform routine maintenance and monitoring.

Content Repository Management

The JCR extension seems to be very interesting as well, as it would give a Java-scriptable access to remote development environments. It could also simply allow content-editors to access and edit remote content, when used in the context of CMS-type apps built on top of a JCR-capable content repository.

What Others Say About CRaSH

An introductory blog post by the CRaSH author, about its use at eXoPlatform. And the fact that it is officially supported by eXoPlatform is an indicator that's it potentially good stuff :)
Not much to read, but of interest: French technologist Didier Girard re-posted it.

Summary

Basically, I see it as a power-user or administrator interface to JVM processes, built on top of Groovy and networking protocols. So it combines the power of scripting with a nice facade and some built-in connectors.

Note on Flexibility

I agree with SK-logic: most of this can be done with most JVM-languages, and they provide more and flexibility. But CRaSH might provide a shorter path to achieving such goals.

The same applies to the JCR extension capabilities: you can achieve this by glueing together a few age-old and time-tested tools. But this might be a shorter and simpler path (like commands for the heroku platform, or PaaS services, for instance).

Java Immutability – When and Why to Use Immutable Pointees

An immutable reference type behaves similarly to a value type.

If String were not immutable, something like this could happen:

String a = "abc";
String b = a;
a.ReplaceCharAt(1, "X");  // this is not possible, if the type is immutable

// b is now "aXc", which might be counter-intuitive

Immutability prevents this from happening: Whenever I assign a string to a variable, I can be sure that this string won't change until I reassign the variable.

On the other hand, we still get the benefits of reference types for String:

In the example above, abc would only be stored once in memory.
Strings can be variable in size.

The latter one is probably the main reason why Strings are reference types in Java and .NET. Often, value types are stored on the stack. To put something on the stack, the compiler needs to know its size beforehand, which is kind of difficult for strings of varying size.