We always tacitly assumed that
protected modifier in java
permits member access from a class the member belongs to, or from an instance of
class's descendant. Very like the C++ defines it, in fact.
In other words no external client of an instance can directly access a protected member of that instance or class the instance belongs to.
It would be very interesting to know how many people live
with such a naivete, really!
Well, that's what java states:
The protected modifier specifies that the member can only be accessed within its own package (as with package-private) and, in addition, by a subclass of its class in another package.
If one'll think, just a little, she'll see that this gorgeous definition
is so different from C++'s and so meaningless that they would better dropped
this modifier altogether.
The hole is so huge that I can easily build an example
showing how to modify protected member of some other class in a perfectly valid
public class MyClass
public void addFacesListener(
public class Hack
public static void addFacesListener(
An example is about to how one adds custom listener to an arbitrary jsf component. Notice that this is not
assumed by design, as a method addFacesListener() is protected. But see how easy one can hack this dummy "protected" notion.
Update: for a proper implementation of protected please read Manifest file, a part about package sealing.
You may find a plenty of JSON implementations in java, so we shall add one more idea. Briefly, it's about to plug it into xml serialization infrastructure JAXB. Taking into account that JAXB now is an integral part of java platform itself, benefits are that you can transparently use the same beans for xml and JSON serialization.
What you need to do is only to provide JSON reader and writer under the hood of XMLStreamReader and XMLStreamWriter interfaces.
In spare time we shall implement this idea.
If you by chance see lines like the following in your code:
private transient final Type field;
then know, you're in the trouble!
The reason is simple, really (provided you're sane and don't put field modifiers without reason). transient assumes that your class is serializable, and you have a particular field that you don't want to serialize. final states that the field is initialized in the constructor, and does not change the value for the rest life cycle.
This way if you will serialize an instance of class with such a field, and then deserialize it back, you will have the field initialized with null, and no way to have another value there.
P.S. That's what we have found in our code recently:
private transient final Lock sync = new ReentrantLock();
Well, we ain't a top news trackers, so only today have found that Micro Focus has acquired Borland.
Once, we were a great supporters of their C++ and Pascal software, but then something has changed. Was it an inspiration that had left them or something else?
Anyhow, their products will live for a long time, but that's a very different kind of life, similar to a lot of COBOL.
Forthcoming update of C++ standard will not include concepts!
This the major backoff is very unfortunate, in my opinion, for C++'s future. Anyhow, there is a strong reasoning behind the decision. WG experienced the lack of resources, and a threatening amount of open questions and inconsistencies related to concepts.
Besides, there is no proper and up to date C++ compiler implementing the feature, which made impossible to verify ideas. All that might delay the C++0x standard up to 2012 or even 2015.
As result WG's decided to move concepts out of scope of the nearest update.
I hope very much that concepts will follow soon after the standard.
Read more at: What Happened in Frankfurt?
|A week ago my brothers had returned from their journey to France. They have brought a reproduction of one of remarkable and meaningful images. The title on it can be used as our motto.
Interestingly enough that a google search for "coolgen java bean generation" leads to our site.
That's a good starting point, as we support such conversions. We, however, suggest to follow to BluePhoenix location. That's where the bosses live.
Generics in C# look inferior to templates (especially to concepts) in C++,
however now and then you can build a wonderful pieces the way a C++ profi would
Consider a generic converter method:
T Convert<T>(object value).
In C++ I would create several template specializations for all supported
conversions. Well, to make things harder, think of converter provider supporting
public interface IConverterProvider
Converter<object, T> Get<T>();
That begins to be a puzzle in C++, but C# handles it easily!
My first C#'s implementation was too naive, and spent too many cycles in
provider, resolving which converter to use. So, I went on, and have created a
sofisticated implementation like this:
private IConverterProvider provider = ...
public T Convert<T>(object value)
var converter = provider.Get<T>();
public class ConverterProvider: IConverterProvider
public Converter<object, T> Get<T>()
private static class Impl<T>
// Heavy implementation initializing converters.
converter = ...
public static readonly Converter<object, T> converter;
Go, and do something close in C++!
Living in Israel, moving almost exclusively in a car I would not experience
what I've seen today in metro of Paris.
On the Ranelagh station an old woman has entered the train. She's in her mid
seventies. Once, she was beautiful. She still is! Colors and features are faded
but her dressing and posture are still elegant. But what's struck me most are
her eyes. Well, they ain't beautiful anymore. I've read a sadness there.
I think she will probably live ten or even twenty years more, but she would give them up just for one year to be younger.
If you have a string variable
$value as xs:string, and want to know whether it starts from a digit, then what's the best way to do it in the xpath?
Our answer is:
($value ge '0') and ($value lt ':').
Looks a little funny (and disturbing).
In our project we're generating a lot of xml files, which are subjects of manual
changes, and repeated generations (often with slightly different generation
options). This way a life flow of such an xml can be described as following:
- generate original xml (version 1)
- manual changes (version 2)
- next generation (version 3)
- manual changes integrated into the new generation (version 4)
If it were a regular text files we could use
diff utility to prepare
patch between versions 1 and 2, and apply it with
patch utility to
a version 3. Unfortunately xml has additional semantics compared to a plain text. What's an
invariant or a simple modification in xml is often a drastic change in text.
patch does not work well for us. We need xml diff
The first guess is to google it! Not so simple.
We have failed to find a tool or an API that can be used from ant. There are a
lot of GUIs to show xml differences and to perform manual merge, or doing
similar but different things to what we need
(like MS's xmldiffpatch).
Please point us to such a program!
Meantime, we need to proceed. We don't believe that such a tool can be
done on the knees, as it's a heuristical and mathematical at the same time
task requiring a careful design and good statistics for the use cases. Our idea
is to exploit
patch. To achieve the goals we're going to
perform some normalization of xmls before
diff to remove redundant
invariants, and normalization after the
patch to return it into a readable form.
- ordering attributes by their names;
- replacing unsignificant whitespaces with line breaks;
- entering line breaks after element names and before attributes, after
attribute name and before it's value, and after an attribute value.
This way we expect to recieve files reacting to modifications similarly to text
Ladies and gentlemen of the jury, exhibit number one is what the seraphs, the misinformed, simple, noble-winged seraphs, envied. Look at this the most ancient program:
At present C# serializer knows how to print comments and do some formatting (we had to create micro xml serializer within xslt to serialize xml comments). C#'s formatting is not as advanced as java's one, but it should not be such in the first place, as C# text tends to be more neat due to properties and events. Compare:
instance.Items.Value = value;
TODO: implement API existing in jxom and missing in C# xom. This includes:
- name normalization - rewriting tree to make names unique (duplicate names are often appear during generation from code templates);
- namespaces normalization - rewriting tree to elevate type namespaces (during generation, types are usually fully qualified);
- unreachable code detection - optional feature (in java it's required, as unreachable code is an error, while in C# it's only a warning);
- compile time expression evaluation - optional feature used in code optimization and in reachability checks;
- state machine refactoring - not sure, as C# has
yield statement that does the similar thing.
Update can be found at: jxom/C# xom.
June, 24 update: name and namespace normalizations are implemented.
Writing a language serializer is an as easy task, as riding a bicycle. Once you learned it, you won't apply a mental force anymore to create a new one.
This still requires essential mechanical efforts to write and test things.
Well, this is the first draft of the C# xslt serializer. Archive contains both C# xom and jxom.
Note: no comments are still supported; nothing is done to format code except line wrapping.
Today an old book was extracted by my son on the light of God. The book was immediatly opened on this verse:
Any trifle can become
a main business of your life.
You just need be a firmly believed
that there is nothing more important that can be achieved.
And then nothing won't prevent you gasp out from delight to engage with this nonsense.
Unfortunatelly too often these facetious verses of Gregory Oster becoming a true.