At the end it gives everyone a core [[Java]] language extensible by libraries. As [[API]] of libraries is easier to evolve than a language, the system would be really powerful and flexible. Having such tiny [[framework]] could end the fragmentation of various of [[Java]] forks and finally bring us closer to having (the same) [[Java]] everywhere.

At the end it gives everyone a core [[Java]] language extensible by libraries. As [[API]] of libraries is easier to evolve than a language, the system would be really powerful and flexible. Having such tiny [[framework]] could end the fragmentation of various of [[Java]] forks and finally bring us closer to having (the same) [[Java]] everywhere.

Designing a [[wikipedia:Software_framework|framework]] with [[API]]s is slightly different to designing an in-house system. There are little differences which may sound like [[paradoxes]]. Mostlz caused by the fact that [[API]]s are like [[star]]s - e.g. designing a [[framework]] is like designing a universe - you never know who's watching and you need to be [[BackwardCompatibility|ready for that]].

Designing a [[wikipedia:Software_framework|framework]] with [[API]]s is slightly different to designing an in-house system. There are little differences which may sound like [[paradoxes]]. Mostly caused by the fact that [[API]]s are like [[star]]s - e.g. designing a [[framework]] is like designing a universe - you never know who's watching and you need to be [[BackwardCompatibility|ready for that]].

== Is [[Java]] Language or a Framework? ==

== Is [[Java]] Language or a Framework? ==

I still have to ask Radim, but I have a feeling he could agree with such ''java.minimal'' system (even including [[modularity]] as part of the language).

I still have to ask Radim, but I have a feeling he could agree with such ''java.minimal'' system (even including [[modularity]] as part of the language).

At the end it gives everyone a core [[Java]] language extensible by libraries. As [[API]] of libraries is easier to evolve than a language, the system would be really powerful and flexible. Having such tiny [[framework]] could end the fragmentation of various of [[Java]] forks and finally bring us closer to having (the same) [[Java] everywhere.

At the end it gives everyone a core [[Java]] language extensible by libraries. As [[API]] of libraries is easier to evolve than a language, the system would be really powerful and flexible. Having such tiny [[framework]] could end the fragmentation of various of [[Java]] forks and finally bring us closer to having (the same) [[Java]] everywhere.

I strongly believe [[modularity]] should be part of the [[Java]] language. But also, I'd like to see the [[Java]] language to remain portable. As such it would really helped if there could be ''java.minimal'' module defined during the modularization of [[Java]]. It would contain all the classes [[JavaC]] references to in its generated bytecode. Porting [[Java]] to new systems would then require just re-implementation of [[VM]] and this '''java.minimal''' module. Everything else would be just optional libraries.

I strongly believe [[modularity]] should be part of the [[Java]] language. But also, I'd like to see the [[Java]] language to remain portable. As such it would really helped if there could be ''java.minimal'' module defined during the modularization of [[Java]]. It would contain all the classes [[JavaC]] references to in its generated bytecode. Porting [[Java]] to new systems would then require just re-implementation of [[VM]] and this '''java.minimal''' module. Everything else would be just optional libraries.

I still have to ask Radim, but I have a feeling he could agree with such ''java.minimal'' system (even including [[modularity]] as part of the language). We would have a core language extensible by libraries. As [[API]] of libraries is easier to evolve than a language, the system would be really powerful and flexible. Having such tiny [[framework]] could end the fragmentation of various of [[Java]] forks and finally bring us closer to having (the same) [[Java] everywhere.

I still have to ask Radim, but I have a feeling he could agree with such ''java.minimal'' system (even including [[modularity]] as part of the language).

 

At the end it gives everyone a core [[Java]] language extensible by libraries. As [[API]] of libraries is easier to evolve than a language, the system would be really powerful and flexible. Having such tiny [[framework]] could end the fragmentation of various of [[Java]] forks and finally bring us closer to having (the same) [[Java] everywhere.

It is clearly true that [[Java]] is not just a language. Certain classes are needed and required by the [[JavaC]] compiler. One needs {{JDK|java/lang|Object}}, {{JDK|java/lang|String}}, {{JDK|java/lang|StringBuilder}}, {{JDK|java/lang|Throwable}}, {{JDK|java/lang|RuntimeException}}, {{JDK|java/lang|Class}}, {{JDK|java/io|Serializable}}, {{JDK|java/lang|Enum}} and potentially few others.

It is clearly true that [[Java]] is not just a language. Certain classes are needed and required by the [[JavaC]] compiler. One needs {{JDK|java/lang|Object}}, {{JDK|java/lang|String}}, {{JDK|java/lang|StringBuilder}}, {{JDK|java/lang|Throwable}}, {{JDK|java/lang|RuntimeException}}, {{JDK|java/lang|Class}}, {{JDK|java/io|Serializable}}, {{JDK|java/lang|Enum}} and potentially few others.

I strongly believe [[modularity]] should be part of the [[Java]] language. But also, I'd like to see the [[Java]] language to remain portable. As such it would really helped if there could be ''java.minimal'' module defined during the modularization of [[Java]]. It would contain all the classes needed by [[JavaC]]. Porting [[Java]] to new systems would then require just re-implementation of [[VM]] and this '''java.minimal''' module. Everything else would be just optional libraries.

I strongly believe [[modularity]] should be part of the [[Java]] language. But also, I'd like to see the [[Java]] language to remain portable. As such it would really helped if there could be ''java.minimal'' module defined during the modularization of [[Java]]. It would contain all the classes [[JavaC]] references to in its generated bytecode. Porting [[Java]] to new systems would then require just re-implementation of [[VM]] and this '''java.minimal''' module. Everything else would be just optional libraries.

I still have to ask Radim, but I have a feeling he could agree with such ''java.minimal'' system (even including [[modularity]] as part of the language). We would have a core language extensible by libraries. As [[API]] of libraries is easier to evolve than a language, the system would be really powerful and flexible. Having such tiny [[framework]] could end the fragmentation of various of [[Java]] forks and finally bring us closer to having (the same) [[Java] everywhere.

I still have to ask Radim, but I have a feeling he could agree with such ''java.minimal'' system (even including [[modularity]] as part of the language). We would have a core language extensible by libraries. As [[API]] of libraries is easier to evolve than a language, the system would be really powerful and flexible. Having such tiny [[framework]] could end the fragmentation of various of [[Java]] forks and finally bring us closer to having (the same) [[Java] everywhere.

On the other hand, when you see [[Java]] as a [[framework]], you need to count the libraries in. And one of the biggest requirement is not only have the libraries, but also have them working on all supported systems the same way. [[Sun]] as a steward of [[Java]] (well known for its ''write once, run anywhere'' vision) was obviously closer to this point of view. Porting such system to other [[environment]] may however proof to be incredibly difficult.

On the other hand, when you see [[Java]] as a [[framework]], you need to count the libraries in. And one of the biggest requirement is not only have the libraries, but also have them working on all supported systems the same way. [[Sun]] as a steward of [[Java]] (well known for its ''write once, run anywhere'' vision) was obviously closer to this point of view. Porting such system to other [[environment]] may however proof to be incredibly difficult.

Forking (as done by [[Google]]) is one way to go. But the proper way is to create [[Modular Java SE]] and make sure the smallest profile can fit to any target [[environment]]. What should be the smallest profile? The current [[Jigsaw]]'s '''java.base''' module has about three thousand classes. That is much better than current [[JDK]] and probably [[good]] enough to fit on a modern phone (which is basically the primary motivation for modularization of [[JDK]] as far as I understand). However it is still way to heavy to be shared base for [[GWT]] or other in browser running [[Java]] system. Dear [[JDK]] team, can't we get something lighter?

Forking (as done by [[Google]]) is one way to go. But the proper way is to create [[Modular Java SE]] and make sure the smallest profile can fit to any target [[environment]]. What should be the smallest profile? The current [[Jigsaw]]'s '''java.base''' module has about three thousand classes. That is much better than current [[JDK]] and probably [[good]] enough to fit on a modern phone (which is basically the primary motivation for modularization of [[JDK]] as far as I understand). However it is still way to heavy to become the shared base for [[GWT]] or other in browser running [[Java]] system. Dear [[JDK]] team, can't we get something lighter?

== [[Java]] Minimal Profile ==

== [[Java]] Minimal Profile ==

[[Google]] brought [[Java]] into completely new places. Got it into browsers (via [[GWT]]), got it to phones (via [[Android]]). When doing that, it become handy to have greater flexibility. While bringing [[Java]] into limited [[environment]]s, one may not be able to implement all the existing [[JDK]] [[API]]s. It helps to concentrate on language only, and treat libraries flexibly. Of course, having built in [[modularity]] stays in a way...

[[Google]] brought [[Java]] into completely new places. Got it into browsers (via [[GWT]]), got it to phones (via [[Android]]). When doing that, it become handy to have greater flexibility. While bringing [[Java]] into limited [[environment]]s, one may not be able to implement all the existing [[JDK]] [[API]]s. It helps to concentrate on language only, and treat libraries flexibly. Of course, having built in [[modularity]] stays in a way...

On the other hand, when you see [[Java]] as a [[framework]], you need to count the libraries in. And one of the biggest requirement is not only have the libraries, but also have them working on all supported systems the same way. [[Sun]] as a steward of [[Java]] (well know for its ''write once, run anywhere'' vision) was obviously closer to this point of view. Porting such system to other [[environment]] may however proof to be incredibly difficult.

On the other hand, when you see [[Java]] as a [[framework]], you need to count the libraries in. And one of the biggest requirement is not only have the libraries, but also have them working on all supported systems the same way. [[Sun]] as a steward of [[Java]] (well known for its ''write once, run anywhere'' vision) was obviously closer to this point of view. Porting such system to other [[environment]] may however proof to be incredibly difficult.

Forking (as done by [[Google]]) is one way to go. But the proper way is to create [[Modular Java SE]] and make sure the smallest profile can fit to any target [[environment]]. What should be the smallest profile? The current [[Jigsaw]]'s '''java.base''' module has about three thousand classes. That is much better than current [[JDK]] and probably [[good]] enough to fit on a modern phone (which is basically the primary motivation for modularization of [[JDK]] as far as I understand). However it is still way to heavy to be shared base for [[GWT]] or other in browser running [[Java]] system. Dear [[JDK]] team, can't we get something lighter?

Forking (as done by [[Google]]) is one way to go. But the proper way is to create [[Modular Java SE]] and make sure the smallest profile can fit to any target [[environment]]. What should be the smallest profile? The current [[Jigsaw]]'s '''java.base''' module has about three thousand classes. That is much better than current [[JDK]] and probably [[good]] enough to fit on a modern phone (which is basically the primary motivation for modularization of [[JDK]] as far as I understand). However it is still way to heavy to be shared base for [[GWT]] or other in browser running [[Java]] system. Dear [[JDK]] team, can't we get something lighter?

We have not resolved our dispute then, but at the end it boiled down to a single question: Is [[Java]] a language or a [[framework]]?

We have not resolved our dispute then, but at the end it boiled down to a single question: Is [[Java]] a language or a [[framework]]?

[[Google]] brought [[Java]] into completely new places. Got it into browsers (via [[GWT]]), got it to phones (via [[Android]]). When doing that, it become handy to have greater flexibility. While bringing [[Java]] into limited environments, one may not able to implement all the existing [[JDK]] [[API]]s. It helps to concentrate on language only, and treat libraries flexibly. Of course, having built in [[modularity]] stays in a way...

[[Google]] brought [[Java]] into completely new places. Got it into browsers (via [[GWT]]), got it to phones (via [[Android]]). When doing that, it become handy to have greater flexibility. While bringing [[Java]] into limited [[environment]]s, one may not be able to implement all the existing [[JDK]] [[API]]s. It helps to concentrate on language only, and treat libraries flexibly. Of course, having built in [[modularity]] stays in a way...

On the other hand, when you see [[Java]] as a [[framework]], you need to count the libraries in. And one of the biggest requirement is not only have the libraries, but also have them working on all supported systems the same way. [[Sun]] as a steward of [[Java]] (well know for its ''write once, run anywhere'' vision) was obviously closer to this point of view. Porting such system to other [[environment]] may however proof to be incredibly difficult.

On the other hand, when you see [[Java]] as a [[framework]], you need to count the libraries in. And one of the biggest requirement is not only have the libraries, but also have them working on all supported systems the same way. [[Sun]] as a steward of [[Java]] (well know for its ''write once, run anywhere'' vision) was obviously closer to this point of view. Porting such system to other [[environment]] may however proof to be incredibly difficult.

Few years ago I got into an argument with ex-[[NetBeans]], ex-[[Google]] developer Radim. We argued whether [[modularity]] should or should not be part of the [[Java]] language. Unsurprisingly (knowing now what [[Google]] did to [[Java]]) Radim was trying to see [[Java]] as a language only (and thus claiming modularity should not be part of it). In contrast, I (as somebody who is using [[modularity]] among [[NetBeans]] libraries every day) claimed that modularity should be essential part of the language (which is my long persisting opinion expressed at [[The Future|epilogue]] of [[TheAPIBook]]).

Few years ago I got into an argument with ex-[[NetBeans]], ex-[[Google]] developer Radim. We argued whether [[modularity]] should or should not be part of the [[Java]] language. Unsurprisingly (knowing now what [[Google]] did to [[Java]]) Radim was trying to see [[Java]] as a language only (and thus claiming modularity should not be part of it). In contrast, I (as somebody who is using [[modularity]] among [[NetBeans]] libraries every day) claimed that modularity should be essential part of the language (which is my long persisting opinion expressed at [[The Future|epilogue]] of [[TheAPIBook]]).

We have not resolved our dispute then, but at the end it boils down to a question: Is [[Java]] a language or a [[framework]]?

We have not resolved our dispute then, but at the end it boiled down to a single question: Is [[Java]] a language or a [[framework]]?

[[Google]] brought [[Java]] into completely new places. Got it into browsers (via [[GWT]]), got it to phones (via [[Android]]). When doing that, it become handy to have greater flexibility. While bringing [[Java]] into limited environments, one may not able to implement all the existing [[JDK]] [[API]]s. It helps to concentrate on language only, and treat libraries flexibly. Of course, having built in [[modularity]] stays in a way...

[[Google]] brought [[Java]] into completely new places. Got it into browsers (via [[GWT]]), got it to phones (via [[Android]]). When doing that, it become handy to have greater flexibility. While bringing [[Java]] into limited environments, one may not able to implement all the existing [[JDK]] [[API]]s. It helps to concentrate on language only, and treat libraries flexibly. Of course, having built in [[modularity]] stays in a way...

== Is [[Java]] Language or a Framework? ==

== Is [[Java]] Language or a Framework? ==

Few years ago I got into an argument with ex-[[NetBeans]], ex-[[Google]] developer. We argued whether [[modularity]] should or should not be part of the [[Java]] language. Unsurprisingly (knowing now what [[Google]] did to [[Java]]) Radim was trying to see [[Java]] as a language only (and thus claiming modularity should not be part of it). In contrast, I (as somebody who is using [[modularity]] among [[NetBeans]] libraries every day) claimed that modularity should be essential part of the language (which is an opinion expressed at [[The Future|epilogue]] of [[TheAPIBook]]).

Few years ago I got into an argument with ex-[[NetBeans]], ex-[[Google]] developer Radim. We argued whether [[modularity]] should or should not be part of the [[Java]] language. Unsurprisingly (knowing now what [[Google]] did to [[Java]]) Radim was trying to see [[Java]] as a language only (and thus claiming modularity should not be part of it). In contrast, I (as somebody who is using [[modularity]] among [[NetBeans]] libraries every day) claimed that modularity should be essential part of the language (which is my long persisting opinion expressed at [[The Future|epilogue]] of [[TheAPIBook]]).

We have not resolved our dispute then, but at the end it boils down to a question: Is [[Java]] a language or a [[framework]]?

We have not resolved our dispute then, but at the end it boils down to a question: Is [[Java]] a language or a [[framework]]?